On 2017-12-12, Jochen Wiedmann wrote: > What I came up with, instead, was a set of conventions, which closely > resemble the Maven projects, and a "Maven Jar Template" (MJT). The MJT > is an Ant build script, which is generic, and shared by all our > subprojects. The actual build scripts typically specify a small set of > properties (project.name, project.version, > project.java.source.version, and the like), and import the MJT. As the > project follows the MJT conventions, that's it in most cases, apart > from things like a uber jar, etc., which aren't handled by the MJT. > However, these are mostly resolved by "overwriting" one of the > imported tasks.
Sounds a lot like the thing we've done for the antlibs where we've got a template build system in https://github.com/apache/ant-antlibs-common and the individual antlibs come down to <project default="compile" name="antunit"> <!-- easy way to override properties --> <property file="build.properties"/> <!-- don't fork junit; regexp classes not available --> <property name="junit.fork" value="false" /> <property name="javac.test-source" value="1.5"/> <property name="javac.test-target" value="1.5"/> <import file="common/build.xml"/> </project> (that's AntUnit, the one for compress is even shorter). > The experiemce is so good, that I wonder, if we couldn't start > distributing some of these templates with Ant Core, or as a separate > ant-templates.jar? If so, a build script could look like below, I'd see this as a collection separate from Ant's core. In a way EasyAnt (and Krysalis years before that) tried to do something like this but may have been too ambitious. Having some sort of best practice template(s) without any additional tooling required might be enough. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
