I would do that, but I want to be able to (from a single codebase) be able to do basically a maven:compile/maven:test and then have Turbine pick up the fact that the class changed, and reload it.. Maybe instead of my hack with webapp:compile that just calls the maven:compile and then moves the class files over into the /webapp sub dir, I could instead tell Turbine to load classes from the /target/classes directory? Not sure about that though, I didn't see anything directly in TR.props....
Having to build a war and then uncompress it everytime I change the code would take too long (I think..), but I want to work within the maven framework as much as possible... Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 7:15 PM To: Turbine Maven Users List Subject: RE: How do people set up Turbine apps using Maven? Eric, my take would be to follow Jon's lead on this one, and make the war/ear tasks build a complete image in /target before doing the zip. This looks like it would help you, right? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers "Eric Pugh" <epugh@upstate To: "'Turbine Maven Users List'" .com> <[EMAIL PROTECTED]> cc: 05/15/02 01:11 Subject: RE: How do people set up Turbine apps using Maven? AM Please respond to "Turbine Maven Users List" I thought I would describe the changes that I made to allow Maven to do a build of my Turbine based web app, somewhat in place! Instead of putting everything in the target directory, I build my app in the webapps/myapp directory, and then I changed my virtual host root in server.conf for tomcat to point to that directory.... Of course, I do some hokie stuff to support maven:war, using the pre and post process tags. I think I am going to remove the copying around of the lib directory, and instead just get the lib directory for the inplace running out of the built war... That way my lib directory is build off of the dependencies of the POM. <target name="war.preprocess"> <echo message="Preprocessing!"/> <move todir="${basedir}/temp/lib"> <fileset dir=" ${basedir}/src/webapps/kinaseprofiler/web-inf/lib"/> </move> <delete dir=" ${basedir}/src/webapps/kinaseprofiler/web-inf/classes/"/> </target> <target name="war.postprocess" depends="webapp:compile"> <echo message="Postprocessing!"/> <move todir=" ${basedir}/src/webapps/kinaseprofiler/web-inf/lib/"> <fileset dir="${basedir}/temp/lib"/> </move> </target> <target name="webapp:compile" depends="maven:compile"> <copy todir=" ${basedir}/src/webapps/kinaseprofiler/web-inf/classes/"> <fileset dir="${basedir}/target/classes/"> <include name="**/*.class"/> </fileset> </copy> </target> Suggestions...? Bring'em on! ERic -----Original Message----- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 7:45 PM To: Turbine Maven Users List Subject: Re: How do people set up Turbine apps using Maven? on 5/13/02 4:19 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > what can we do to help with how Scarab does it's build? I would like to see Maven conform to Scarab's methodology for building itself. Scarab uses a sandbox methodology which allows the build process to function as a tool to generate everything into a "target" directory. This directory is special in that nothing in the original cvs checkout is modified in place...everything that is needed is copied into the target directory. The target directory is special because it is essentially a webapp directory. So, if you change a file in scarab/src/java/* and run ant, then it gets compiled into scarab/target/webapps/scarab/WEB-INF/classes so that the change is immediately seen. Scarab also does things like execute Torque on the fly to generate the code and SQL files into the right locations. Lastly, we also have targets in the build.xml to build Scarab's many number dependencies. Scarab's system does some tricky and complicated stuff, but it does it very cleanly and the build process is very easy to use. -jon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED]> For additional commands, e-mail: < mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
