I’m realizing that my productivity since I moved has been severely reduced by the setup of my loft here in Irvine compared to the office I had back in Brooklyn. Herewith are some resolutions and plans for fixing that. Suggestions are appreciated.
Many Java projects are divided into multiple subprojects or modules, each in its own directory. Often you’ll want to build subprojects individually, without necessarily building all of the larger master project. For example, in my XOM project, I have one master build.xml file that builds the software itself, and another build.xml file in the web directory that builds the web site. jEdit is divided into separate jedit, jeditshell, macros, and plugins directories, each of which has its own build.xml file.
Furthermore, projects may have dependencies on other projects. For instance XOM 1.1, JDOM, and dom4j all depend on Jaxen. For the latest and greatest JAR, Jaxen should be rebuilt using its own build.xml file, rather than bundling a stale JAR archive that’s months or even years beyond its expiration date.
You could cd into each separate diretory and type ant compile in each one, but that’s time conmsuming and error prone. Plus interproject dependencies may require this to be done in a precise order that makes this even more error-prone. It’s preferable to create a master build file at the top level that compiles everything by invoking targets in the other build files. The ant task lets you do this. For example, this task executes the build.xml file in the directory website (relative to the directory where the current build.xml file is) :
(more…)
The usual SourceForge CVS instructions ask you to check out modules like so:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jedit login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jedit co -P modulename
Of course many projects are divided into multiple modules, all of which are required. You can check out the entire project, including all of its modules like this:
(more…)
