ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: ANT 1.7 features suggestion
Date Tue, 04 May 2004 20:32:29 GMT
Anthony Goubard wrote:

> Hello,
> A few weeks ago, there was a discussion about the new features in ANT 1.7.
> I've made a list of features that I think would be useful in ANT and 
> that I'd like to discuss on this mailing list.
> Maybe some of you would have a usage of these new feature for your 
> existing ANT code.
> 1) Integrate if and unless at the Task level.
> This would allow all ANT tasks to have the if and unless attribute (the 
> same way that it has an id attribute).
> So far the only way to do it is by using <target> except if you use one 
> of the task which has already the "if" "unless" attributes such as <fail>.
> I think ANT users would use this feature to remove some tartget created 
> only for the purpose of the "if" or would remove the ant-contrib <if> task.

1. I dont think new attributes are the right approach -unless you want 
to use namespaced attributes.
2. is it so hard doing it at the target level?

> 2) Same thing for the components fileset, mapper, include?, ...

these could take conditional attributes more easily, though junit 
filesets already have them, I think.

> 3) Regexp conditions
> I think these conditions would be useful for ANT
> <containsregexp> and <matchesregexp>
> The first one would test a string if it contains a regular exression.
> The second one would test if a string matches a regular expression.
> Note that we don't need to create new conditions we could also extend 
> the <equals> and <contains>

seems reasonable

> 4) Add an "overwrite" attribute at the property task.
> Properties are immutable but sometimes I think that you would like to 
> change a propety.
> The way to do it is to use <antcall> with <param>, now you would be able

> to redefine an property with overwrite="true".

you might think this is a good idea, but when you try invoking ant tasks 
from other places then you will see why it is trouble and never likely 
to be implemented. Support for local definitions inside a <macrodef> is 
a different matter.

> 5) Merge some jar files
> There are too many jar files in the lib directory, here is a proposition 
> to reduce the number of jar files:
>  Remove ant
>  - Remove ant-launcher.jar and integrate the classes to ant.jar, this 
> would also imply that the loading of the class Main is done using 
> reflection and not using an interface as it is now.

But the reason for the split is precisely to get classloading right. 
Surely this will break it.

>  - I think that more than 50% of the users uses Java 1.4 and all the 
> tasks that can be realized with 1.4 should be in the same jar file :
> xalan, xslp, swing, sound (it's even ok for me it's in ant-nodeps.jar)

hmmm. What about the others?

>  - put all J2EE tasks together
>  - all tasks that uses apache or open source in ant-osi.jar 
> (ant-commons-*.jar, ant-apache-*.jar, junit, ant-jakarta-*.jar, 
> ant-jdepend.jar, ant-jsch.jar)
>  - all tasks using external sun java lib (jmf, javamail, jai)
>  Any other suggestion is welcome.

The reason for the split was to deal with classloading stuff; you can 
move things out of core and declare them in <taskdefs>. Merging stuff 
takes this facility away. Now if you dont want it you can always 
recombine your jar files.

> 6) Get the properties from a target after antcall
>  At the moment if you have a target that define some properties, the 
> only way to call it in order to get the values is using "depends".

that is precisely the reason for the depends stuff. To declare the oeder 
you want things.

>  This is a problem as you may want to invoke your target not necessary 
> at the beginning or you may want to pass some parameters.

>  That's why it would be nice to have a "keepProperties" (or whatever) 
> attribute to the <ant> and <antcall> task.

If you are doing lots of antcall, have you looked at presetdef and 
macrodef? We have reworked may build files to use these, and make almost 
no use of antcall, which is very, um, procedural and not as fast.

Show us some of your build files, and perhaps we can suggest ways to use 
ant that are more in line with the stuff we added to ant1.6. If we cant, 
then you have a better case for your features.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message