Hmhm. The unix version (build.sh) added *all* jars in the lib directory to the classpath, which made the "drop into lib and call build.dh" much easier. If this has to be done in build.xml, there's trouble ahead with jars containing release identifiers and such ugly stuff. Well, the build.bat had tis problem for ages.
In the medium term, I think some sort of protocol for provides/requires and versioning will have to be established for matching jars. It has always galled me that everyone bundles everything to ensure that a particular application runs.
I'm contemplating mavenizing the build. I've got the personal advantage of working on commons-math which is also mavenized, and I have the repository already. OTOH I have no idea whether and how well mave would handle dependencies on Jimi, JAI, LotBC and other odd non-apache stuff.
What does mavenizing entail?
Incidentally, in the alt.design build, I have separated Version.java into its own package, and I compile it separately at the beginning of the build process to obtain version information for the rest of the build. A package is probably overkill. Fop.java and Version.java should probably belong to org.apache.fop.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>