ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Immutable Properties in 1.1?
Date Thu, 20 Jul 2000 22:44:52 GMT

> -----Original Message-----
> From: Jesse Glick []
> I should mention that I have done some work on an 
> experimental patch to
> the core (I know, hisses) which should permit you to specify templates
> for targets rather than concrete targets. The syntax is pretty simple,
> using regular expressions (not ideal but simple to understand and very
> flexible):
> > <target name="jar1">
> >   <property name="jarfile" value="jar1.jar"/>
> >   <property name="includes" value="**/somefiles"/>
> >   <!-- some code that uses ${jarfile} and ${includes} -->
> > </target>
> > 
> > <target name="jar2">
> >   <property name="jarfile" value="jar2.jar"/>
> >   <property name="includes" value="**/someotherfiles"/>
> >   <!-- some code that uses ${jarfile} and ${includes} -->
> > </target>
> This would become:
> <project name="xxx" basedir="." default="all-jars">
>   <target name="all-jars" depends="jar1,jar2"/>
>   <target pattern="jar([0-9]+)">
>     <echo message="Running target $[0]..."/>
>     <someJarTask jarfileToUse="jar$[1].jar"
>                  includeList="**/someotherfiles-$[1]"/>
>   </target>
> </project>
> No property mutation or copy-and-paste required. For those 
> familiar with
> GNU make, this is similar to use of % patterns in make targets, except
> more flexible (regexps vs. shell patterns, and multiple match
> substrings). You can have as many templates as you need; the first one
> which matches a required target name will be used.

The problem I have with this is that relies on string matching to define
arguments. If I need to add an extra argument, then I need to redefine the
pattern rules that extract the arguments from the call. 

> I would appreciate any thoughts on whether people would find this sort
> of thing valuable, or if there is an obvious way to get the 
> same effect
> with Ant as it is. I guess you can run an Ant sub-project but 
> that seems
> rather cumbersome. Hopefully the syntax does not appear too wretched.
> One caveat: <script> will not see targets from template 
> unless they had
> been instantiated anyway; I do not see any way around this.

Can't we achive the same thing by just writing the following:


<project name="xxx" basedir="." default="all-jars">
  <target name="all-jars" depends="jar1,jar2"/>

  <target name="jar1">
   <ant dir="." target="jar" >
     <property name="jar.arg1" value="jar1" />
     <property name="jar.arg2" value="1" />

  <target name="jar2">
   <ant dir="." target="jar" >
     <property name="jar.arg1" value="jar2" />
     <property name="jar.arg2" value="2" />

  <!-- his is the subrutine -->
  <target name="jar">
    <echo message="Running target ${jar.arg1}..."/>
    <someJarTask jarfileToUse="jar${jar.arg2}.jar"
This is just calling ANT as a subroutine. And it works just fine.
The trick being that you need to make certain that the properties used
for parameters are not defined in the build.xml file outside of
the ANT tasks.

Maybe we could have a new task <calltarget> that is just the same 
as the <ant> task but applies to the same file and directory.
We could use <param> instead of <property> for the parameters to be passed
one wants to make things less confusing. This will just remove the
of being doing a "recursive" make file. We can eventually optimize this
the parser is not needed, we just need to manage the property definition

Does anyone see any problem on using ant this way or implementing such a

Doesn't this solve the problem people had?

Jose Alberto

View raw message