ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Ant templates and more templates
Date Wed, 04 Oct 2000 00:38:10 GMT
Writing some build files for our projects here I have come across several
situations in which I would have liked having some sort of template
facilities for ANT.
(1) This first is for tasks. The <java> tasks that I use are quite quite
monotonous: Call this class with this arguments, then call it again but just
change the last arguments, etc, etc.
One way to deal with this is to define my own task that extends <java> and
that presets all that needs to be preset. But wouldn't it be nice to have a
way to say tell ANT to do that without a need to declare and maintain new
Something like:
<javataskdef name="mytask" classname="XYZ" >
  <classpath refid="XYZpath" />
  <arg value="fix value" />
Now I should be able to use:
<mytask fork="yes" >
  <arg value="changing value" />
And this should be equivalent to doing:
<java classname="XYZ" fork="yes" >
  <classpath refid="XYZpath" />
  <arg value="fix value" />
  <arg value="changing value" />
(2) A second situation where templates are interesting is when trying to
interconnect tasks from on build file to another using the <ant> task. In
this case one usially want to have access from the marter build file to the
suordinate build files. Usually one would have <target>s like:
<target name="subtarget1"  depends="..." >
  <ant target="subtarget1" antfile="subproject.xml" />
Every time you add a task to the subproject, you need to add an entry point
in the project. A real syncronization problem. What I would like is to be
able to say:
<target template="sub*" key="subtarget" depends="..." >
   <ant target="${subtarget} antfile="subproject.xml" />
So with a call like:
    ant subtarget1 subtarget2
ANT will execute the above template twice, once for each substitution and
call the respective subtarget1 and subtarget2 in subproject.xml. Now notice
that the template mechanism is more generic than just calling subprojects.
It will allow for some nice things.
I do not think that (2), in particular, can be solved with XSLT because you
only know the substitution at execution time.
Does this looks as something interesting to have? I think the approach is
quite declarative in both cases, does anybody see a major problem with this?
Jose Alberto


View raw message