> 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
OR/AND/XOR):
- 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
logic
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+
developers)
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
AntBuilder...
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
