Jason van Zyl wrote:
>
> I have personally started using an installed version of
> Ant and I place all the jars I need for building in the
> $ANT_HOME/lib directory. I have actually found this to
> be a lot easier when building multiple projects.
Instead of actually copying jars, what many Jakarta projects are moving
towards is
<property file="build.properties"/> <!-- Component local -->
<property file="../build.properties"/> <!-- Commons local -->
<property file="${user.home}/build.properties"/> <!-- User local -->
With a properties file that looks something like:
# -------------------------------------------------------------------
# EXTERNAL DEPENDENCIES
# -------------------------------------------------------------------
# junit.jar -- JUnit classes (http://junit.org)
junit.jar=/java/junit/junit.jar
# sax2.jar -- SAX 2 classes (http://megginson.com/SAX/)
sax2.jar=/java/sax/sax2.jar
# j2ee.jar -- J2EE classes (http://java.sun.com/products/j2ee/)
j2ee.jar=/java/j2ee/j2ee.jar
For what it's worth, I go a step further and use Gump for my daily
development. Instead of a properties file, there is a small XML file per
project which describes either where to find the project or how to build
it. You can find an example at:
http://jakarta.apache.org/builds/gump/latest/project_jakarta-turbine.html
If you look at it you will see that it depends on the velocity project
definition (done externally), optionally will make use of freemarker if it
is availalbe, and contains a self-contained definition of XML-RPC -
including a reference ot the jar inside of the CVS. This particular
project definition even contains the definition for a second buildable
project, namely torque.
The way this works is that Gump has a generation step that consumes all of
these definitions and builds a single consolidated script for you - right
now this can be done either as a shell script, a batch file, or an Ant
build.xml. At the moment, these three have slightly different
functionallities. In the case of the batch file or shell script, what I
can do is:
build jakarta-turbine
Which will build jakarta-turbine with the default target. Optionally, I
can add Ant options and targets, thus:
build jakarta-turbine -verbose -Doptimize=on package
Scripts are also generated to update projects which come from cvs. In a
single command, you can update all of the sources to the projects you are
interested in, either by name:
update jakarta-velocity jakarta-turbine
Or simply specify all
update all
The all "target" also works for the build script, and has a nice additional
feature that it produces a web page that summarizes all of the results.
Early on inthe development, I build a small script which would invoke "gen
&& update all && build all" which I named "guba", from which ulitmately
Gump got its name.
There are other aspects of Gump that I have not touched on - for example,
the definition of a workspace which describes overall which projects you
are interested in, global options, and repository defintions. And a
profile which describes a common set of projects definitions that a
workspace can draw from.
> I have always liked having jars in CVS for ease of
> use, but I think that if for every project I built
> kept all required jars in CVS I would have 50 copies
> of Ant and Xerces lying around. Until something like
> CJAN is working I wouldn't want to remove all the jars.
> But I think moving in the direction of removing jars
> from CVS and using something like CJAN is the right
> way to go.
Putting jars in CVS optimizes for the use case of a developer who is
interested in only one project or a small set of independent projects.
This is an important use case.
CJAN certainly has a role for people who simply like to install software
and run with it. But as Java requires a compilation step - something that
CPAN users don't have to deal with, I suspect that many Java developers
will prefer to get source.
Jason, if you are building dozens of projects, I would be interested in
your feedback (in words or patches) on some of the ideas in Gump.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
