ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: ANT 1.7 features suggestion
Date Wed, 05 May 2004 08:02:07 GMT
>  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.
>  2) Same thing for the components fileset, mapper, include?, ...

Why not on ProjectComponent? I thought about that ... but not very deeply.
And on that level we´ll get problems with external tasks (on our own we
can delete the if/unless-attributes, e.g. in junit-<test>).
Maybe the namespace could be more helpful.

"if/unless should accept a list". 
Then we´d have to specify what should be true (how they are combined
- if: AND - all properties have to be set
- unless: OR - one property will stop the execution
Another approach would be a new PropertyHelper. I thought about that when
I had played with the JXPath-example in the proposals. More complicated
could be realized then
  if="${logic: prop1 AND (prop2 OR prop3)}"

>  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>

is ok.

>  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".

I wouldn´t merge the immutable/override theory ... If a user sees a
property it should be immutable. 
AntContrib (and several others) has a <variable> task, which could be
helpful. The question would be, if we want to introduce that?

>  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.
>   - 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)
>   - 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.

Have you trouble with the number of jars? I don´t know how many I have in my
ant\lib directory - it just works :-)
I have no problems with Eclipse (3.0M7) on Win2000...

More useful would be breaking Ant into several modules - AntLibs. Plus an
automatic loading if they are in a special place (e.g. in ant/lib :-) 

I would prefer make the Ant-launcher more general, so that you could use
that in your own projects. 

Regarding JDK 1.4 I aggree with Ken - I would prefer the 1.4 or 1.5, too.
But I´d managed the software environment of a large project (200+
and the test scenario was very ... nerve-racking.

>  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".
>   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.

Sounds for a <return> task or a <antcall returnproperty=""/>.

>  Let me know if you want me to implement some of my ideas or 
> report some 
> of them in Bugzilla.

Better here, but we can put a link to the mail-archive on that bugid.

I think there are some basic modifications:
- if/unless on task/component-level (1,2)
- overidable variables (4)
- return values (6)
They are useful, indeed, but then we would move the buildfile more into a 
scripting language. And if a scripting language - why xml-based? We could
spend some time on other things - especially because Groovy has a nice


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

View raw message