ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: Ant <project> extension, templatized build files
Date Thu, 02 May 2002 15:59:20 GMT
For something related to what you do in parent.xml, the post below uses
Javascript to call all the subprojects. Note how it sets dir attribute of
<ant>... You may want to do the same in your parent.xml. --DD

-----Original Message-----
From: Steve Allan [] 
Sent: Thursday, March 28, 2002 7:19 PM
To: 'Ant Users List'
Subject: RE: Passing targets to subprojects with ant using javascript

After reading the antlist archive a little better, I found a thread from
January that matched my situation in which Peter showed a way which is much
better.  Turns out I was trying to do it backwards.  Instead of having my
subproj script be a dependency for my targets, it's much more natural to
have the targets call the script.  As Peter suggested:

<target name = "clean">
 <antcall target = "call">
  <param name = "" value = "clean"/>

Then all references in the javascript are to "call", instead of the target
I'm trying to pass.  Don't know what the heck I was thinking before!

My modified example is included below just to complete the thread - critique
is always welcome.


-- Steve

  <!-- clean target -->
  <target name = "clean">
   <antcall target = "dosubproj">
    <param name = "target" value = "clean"/>

  <!-- dosubproj target calls ant in each subproject and passes target -->
  <target name="dosubproj">
   <script language="javascript"><![CDATA[
      // Add new subprojects to this array.  They'll be built
      // in the order they appear in the array.
      var subproj = new Array(
	list snipped to save space
      for (i = 0; i < subproj.length; i++) {
         target = new"target"));
         build = testproj.createTask('ant');
         build.setDir(new"basedir") + "/"
+ subproj[i]));
         // Pass the target name unless it's the default target
         if(target != "") {
      }]]> </script></target>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

-----Original Message-----
From: Chad Loder [] 
Sent: Wednesday, May 01, 2002 10:55 PM
To: Ant Developers List
Subject: Re: Ant <project> extension, templatized build files

Peter wrote:
 > I would recomend you have a look at the existing projects as they are
 > likely to be imediately usable by you.

I am personally turned off by what I've seen of Maven and
(to a lesser extent) Centipide. Ant is attractive because
it aims only to be a great, NEUTRAL build tool. Using ant by
itself implies no particular project management/structuring
ideology (i.e. "eXtreme programming", "The Apache way (tm)"
or whatever the buzzword of the year is).  I don't want anyone
telling me how to structure my projects, how to do my unit testing,
etc. Rather than using Maven and struggling to turn all the
unwanted stuff off, I would like to use ant and build what's
necessary from scratch.

To sum it up, I don't think one needs all the Maven baggage
to implement templatized buildfiles. Kudos to the Maven people
and's just not how I do things.

Therefore let me re-state my problem in the simplest way I
can. "Given a set of subprojects whose buildfiles share a high
degree of redundancy, how do I reduce this redundancy by factoring
the redundant portions into a single buildfile, while retaining the
flexibility to override the definitions of particular targets."

Having thus restated my problem, I sat down and played with
ant 1.4, coming up with a solution that does what I need,
without requiring any ant changes whatsoever.

I describe my solution below -- I'd like to know what people
think of it. Peter, in particular, I think you and I may be trying to
solve different problems (my needs being somewhat simpler).

I'd like to get comments on this proposed solution (improvements?
possible complications or limitations down the road for large


Assume there is one main project "parent" which consists of
two similar "Sibling"-style subprojects, "brother" and "sister".
The steps required to build a Sibling are always the same,
subject to minor differences subproject-specific differences
(compile flags, pre-build and post-build steps, etc.).

If one had other kinds of subprojects (e.g., in addition to
Siblings, one wanted to build WinExe's or WinDLLs, etc.),
one could make a template-winexe.xml, template-windll.xml,
and so on.

I created 4 build files:

	build.xml: the parent build file
	brother.xml: the build file for the "brother" subproject
	sister.xml: the build file for the "sister" subproject
	template-sibling.xml: the "Sibling" template


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message