Yes, big +1, Right now the dependencies in the cvs'd project.xml are not fleshed out for beanutils and junit
I think project.xml is OK, between this and jakarta-commons/project.xml everything necessary is there. We should probably indicate somewhere in our developer notes that you need to grab jakarta-commons/project.xml and put it in ../jakarta-commons. Maven will croak with strange errors if this file is missing.
I suspect junit also needs to also be there for the "test" target to work properly in Ant even thought its available in mavens lib dir, people using Ant are not using maven and the generated build.xml needs to get junit.It does, but the generated build.xml grabs it as well.
-Mark
Phil Steitz wrote:
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 ibiblio.org -- e.g.,
<get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar";>
</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.
2. Modify build.xml and build.properties.sample 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?
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
