commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [math] maven magic and build.xml -- how to get ant build working again
Date Sun, 01 Jun 2003 16:32:17 GMT

On Sun, 1 Jun 2003, Phil Steitz wrote:

> Date: Sun, 01 Jun 2003 09:14:56 -0700
> From: Phil Steitz <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: [math] maven magic and build.xml -- how to get ant build working
>     again
> Our ant build (and hence nightly) is currently broken, since we have
> added dependencies on commons-beanutils, bringing along collections and
> logging.  I personally have moved to maven entirely, but I thought we
> had agreed early on that we would maintain the ability to build from
> ant.  Also, Craig pointed out that if we want nightly builds, we need to
> have a working build.xml.
> I see two ways to handle this:
> 1. Run maven ant:generate-build and replace build.xml with the result.
> This will add a get-deps target telling ant to grab the jars from
> -- e.g.,
> <get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
> ignoreerrors="true"
> src="">
> </get>
> This works for me from the command line; but something tells me the
> nightly build might not like it and I have no idea whether or not the
> whole script has some hidden dependencies on maven.

Commons-FileUpload (among others) has a build.xml generated by Maven, and
it seems to run fine for the nightly builds.  As long as the "clean" and
"dist" targets can be generated, and the output of the "dist" target goes
in to a "dist" subdirectory, Maven-generated build files should be ok.

> 2. Modify build.xml and to include
> commons-lib.home, commons-beanutils.jar, commons-logging.jar and
> commons-collections.jar properties and expect the user (or bot) to fill
> these in, grab the jars and put them in the specified directories.
> The advantage of 1. is that it guarantees that builds from maven and ant
> use the same jars.  The advantage of 2 is that build.xml is simpler and
> more standard.
> What are other maven-based projects doing to handle this?

I'd definitely go with option 1 -- that way, you don't have to manually
keep the two in sync.  Just regenerate the build.xml when dependencies are

> Phil


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message