ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <sbaill...@imediation.com>
Subject RE: a few enhancements for ant 1.4B2
Date Sun, 26 Aug 2001 08:41:52 GMT
> -----Original Message-----
> From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]


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. 



Mime
View raw message