ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schmetzer <>
Subject Re: Strategies for reusing targets that require paths
Date Tue, 28 Jul 2009 20:24:19 GMT
Hi David,

I have used a similar technique in the Ant Script Library:

You use your scenario of running unit tests, the ASL defines a number of
targets which set default values for the test classpath, the test cases, and
any other resources. It uses a combination of properties, filesets and
classpaths to configure the compilation and test run targets. In general, I
don't use "ant-call" often at all. Refer to for details, or download the
ASL to have a peek at the implementations.


2009/7/28 KARR, DAVID (ATTCINW) <>

> If I have a number of projects with some similar build needs, it's
> reasonable to define reusable targets in a "commons" project build.xml
> file and import that file from each project's build.xml file.  What are
> good strategies for reusing those targets effectively, when they
> certainly require numerous parameters to work properly?  For instance, a
> reusable "junit" target would likely depend on something like a
> "compile-test" target, which would need to be parameterized with the
> source directories to compile, and the "junit" target would need to be
> parameterized with the required classpath.
> If I were constructing this, I would aim for all the reusable targets to
> be called with "ant-call" along with "param" elements.
> If I were building all of this in a single build.xml, I would define
> "path" properties that are referenced with "refid" attributes.  How
> would this work if I were passing those path parameters with "ant-call"?
> If I were to define a path parameter in each of the child build.xml
> files, using the same "id" value, what happens when a target from the
> parent build.xml is executed, which references that path id value?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message