> -----Original Message-----
> From: Alejandro Abdelnur [mailto:[EMAIL PROTECTED]
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"/>
> 2* <property> task, new "override" attribute
> <property file="config/project.properties"/>
> <property file="config/${group}.properties" override="yes" />
> <property
> file="config/${machine}/${developer}/${configuration}/user.properties"
> override="yes" />
> this allows groups and developers to override global (default) values.
What about :
<property
file="config/${machine}/${developer}/${configuration}/user.properties"/>
<property file="config/${group}.properties"/>
<property file="config/project.properties"/>
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 ?
> 3* <property> task, new "eval" attribute
I guess what you are looking for is something like nested evaluation of
properties no ?
<property name="module.name" value="${${module}.name}"/>
> 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.
> 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
> "target.name" 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 ?
> 6* <ant> task, new "fallbackantfile" attribute
I don't think this can be generalized this way...
why is there no fallback for the fallback ? :)
This is related to our "conditional" task execution...
--
St�phane Bailliez
Software Engineer, Paris - France
iMediation - http://www.imediation.com
Disclaimer: All the opinions expressed above are mine and not those from my
company.
