ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <>
Subject Re: a few enhancements for ant 1.4B2
Date Mon, 27 Aug 2001 17:55:00 GMT

thxs for your reply, comments embedded.



Stephane Bailliez wrote:

> > -----Original Message-----
> > From: Alejandro Abdelnur []
> Warning, I will be a real pain below, I'm just trying to understand :)
> > 1* <target>, modified "if" and "unless" attributes
> >
> > the value of the if an unless can be a property name (as it
> > is right now
> > in ant) or a property name/value, i.e:
> >
> >     <target name="tomcatDeploy" if="server.type=tomcat">
> >
> > this target will only be executed if "server.type" is defined and and
> > its value is "tomcat"
> [...]
> What about:
> <target name="serverDeploy" if="server.type">
>         <antcall target="${server.type}Deploy"/>
> </target>
> <target name="tomcatDeploy"/>
> <target name="weblogicDeploy"/>
> <target name="resinDeploy"/>

colin's reply is a good justification for this proposed enhancement.

>  2* <property> task, new "override" attribute
> >     <property file="config/"/>
> >     <property file="config/${group}.properties" override="yes" />
> >     <property
> > file="config/${machine}/${developer}/${configuration}/"
> > override="yes" />
> > this allows groups and developers to override global (default) values.
> What about :
> <property
> file="config/${machine}/${developer}/${configuration}/"/>
> <property file="config/${group}.properties"/>
> <property file="config/"/>
> You are indirectly assigning priorities via your override property here.
> I understand the use of "override" in another context but shouldn't it be a
> property of the 'original' property to be overridable or not ?

the example it is not the best. the fact is that it proven useful for us to have
the ability to change the value of an existing property.

i went for the simple aproach that "user properties"are read only and "project
properties" can be modified using the override attribute.

you suggestion of doing it at property level it's good, thus this would require
some changes in the the Hashtable storing the properties. the value would have
to be a struct "String value,boolean readOnly", then an existing property would
be modified only if readOnly is set false, the readOnly would be set only when
the property is first defined using a "modifiable" attribute.

> > 3* <property> task, new "eval" attribute
> I guess what you are looking for is something like nested evaluation of
> properties no ?
> <property name="" value="${${module}.name}"/>

yeap, are there any plans to have nested evaluation ?

> > 4* <antcall> task, new "iterate" and "iterator" attributes
> >
> > it allows to execute the antcall task in a looping way. the iterate
> > attribute contains the list (space separated) to iterate through, the
> > iterator attribute defines the name of the property that will contain
> > the element of the current iteration. for example:
> it's related to <foreach> (*huge* number of posts related to this...)
> I will not put your iterate as a property for a target because you can see
> that it can be used in many situations.

i'm new to the alias, i'll look the history of this in the mail archives.

> > 5* "*DEFAULT*" target name
> >
> > if a target in the ant build file is named "*DEFAULT*", it will be
> > invoked if the invoked target does not exist. this provides a
> > mechanism
> > similar to the default in a switch statement. a property named
> > "" will contain the name of the invoked target.
> [...]
> > this provides a useful hook to delegate targets to other ant
> > build files without having to know them.
> Strange to me...if you don't agree on a common interface (ie entry point),
> how do you know that your default target will do what you want it to do ?

let me give an example of this.

our development environment consists of several logical modules, i.e.: utilsB,
utilD, shoppingcartB, shoppingcartD, webservices.

the common targets are: init, build, deploy, install, cleanBuild, cleanDeploy,

the ant build.xml is generic for all modules and for several projects.

all the targets run in all the defined modules (using the loop mechanism defined

the webservices modules requires a special target "registerServices".

the build.xml file has *DEFAULT* target:

<target name="*DEFAULT*" depends="init">
    <ant target="" antfile="${workspace}/config/custom.xml"/>

the custom.xml is per project.

thus, this allows to have project specific targets while still sharing a single
entry point build.xml.

> > 6* <ant> task, new "fallbackantfile" attribute
> I don't think this can be generalized this way...
> why is there no fallback for the fallback ? :)

here i went for the simplest, one level of fallback. i do not see anything that
would prevent for going to a multilevel (chain) model.

> This is related to our "conditional" task execution...

yes, you could simulate all this with the condition task:

<target name="build">
  <property name="" value="config/moduleBuild.xml"/>
  <condition property="" value="${module}/config/moduleBuild.xml"/>
  <antcall target="customBuild"/>
  <antcall target="genericBuild"/>

<target name="customBuild" if="">
    <ant target="build" antfile="${}"/>

<target name="customBuild" if="">
    <ant target="build" antfile="${}"/>

but with the fallbackantfile attribute it's just:

<target name="build">
  <ant target="build" antfile=""${module}/config/moduleBuild.xml"

View raw message