Hi Oleg, > This all leads to believe that we will be much better off with > self-contained build.xml and should do away with build-common.xml. The > inevitable duplication of common tasks in individual build files seems > like a lesser evil to me.
I have reconsidered. Something in build-common.xml is seriously broken, and I believe it's got to do with those "macro" definitions. I believe that mainly because I never used them, and it seems to be the only thing that might cause trouble. In particular, when I give more than one target that actually does something, the build fails with message "Element more-src already present". Examples: ant clean compile javadoc ant clean compile package ant clean package javadoc ant clean package test ... The Ant based build process is in need of a fundamental overhaul. When I consider the build files I write at work, they also define all component specific knowledge in the local build.xml, including <javac> and <jar> tasks. The shared definitions are only fundamental things, like a timestamp that can be used by each component during the build, and some properties. So I am in favor of creating self-contained build files for each component. When doing so, we also should reconsider the structure of the build. Currently, our Ant build tries to replicate a subset of the Maven build lifecycle. I'm not sure what value this adds, unless we want to let Maven call our Ant targets. Separating the target and temporary directories used by Maven and Ant might also be a good idea. And finally a feature request: do *not* make the javadoc target depend on the compile target! Whenever I change an interface and then run "ant clean compile" to see from the errors which classes I have to adapt, I am left without javadocs until I've finished the changes for which I would like to use them :-( cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
