You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Anthony Goubard <ad...@chello.nl> on 2004/05/04 19:00:43 UTC
ANT 1.7 features suggestion
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.
2) Same thing for the components fileset, mapper, include?, ...
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>
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".
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.
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.
Let me know if you want me to implement some of my ideas or report some
of them in Bugzilla.
Ciao,
Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ANT 1.7 features suggestion
Posted by Stefan Bodewig <bo...@apache.org>.
I'm soo late for the party that I'll try to not restart the whole
thing.
On Tue, 04 May 2004, Anthony Goubard <ad...@chello.nl> wrote:
> 1) Integrate if and unless at the Task level.
A nested <condition> would be far more powerful, as would be an <if>
task. Don't expect any opinion from me. 8-)
> 3) Regexp conditions
SMOP.
If anybody wanted to code them up (using Ant's regexp engine
abstraction layer, of course), I'm sure there wouldn't be any
objections.
> 4) Add an "overwrite" attribute at the property task. Properties
> are immutable but sometimes I think that you would like to change a
> propety.
I don't think this would be a good idea since immutability is
something that the parent build file relies upon and adding the
attribute would give the child build file control over it. An
overwritable attribute that the parent could set would be more inline
with the intent of Ant (why properties are immutable). Not that I was
advocating it.
Most cases where you've used <antcall> with <param> can be replaced by
<macrodef> and your "need to be mutable" properties become attributes
that way. I've found that this addresses most needs for mutable
properties at the same time.
> 5) Merge some jar files
Would defeat the reason why we've split up optional.jar in the first
place.
> - 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,
Some of our users run Kaffee with the swing classes for Java 1.1 from
Sun. You may want to load the swing lib via a different classloader
than main Ant. Same for TraX/Xalan and any JDK < 1.4.
> 6) Get the properties from a target after antcall
Would immediately break tons of builds that rely on throw-away
properties during <antcall> if it became the default. You probably
wouldn't want to keep all properties anyway, just a few of them.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ANT 1.7 features suggestion
Posted by Anthony Goubard <ad...@chello.nl>.
Steve Loughran wrote:
> 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?
Well, I find it quite ugly, let's say you have it 10 times in your build
files, it creates more code, when editing your files you also then need
to navigate between your target and all the other targets at the bottom
of the files which were created only for the if condition and only
contains one task like for example <echo>. I also saw a few weeks ago
some asking in this list for a "if" "unless" for another task.
I don't see the problem of adding new attributes as long as they're
useful and optional.
>> 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.
>
I think that overwrite should most of the time not be use and the
default behaviour should be of course "false". If you use overwrite, it
should be explicit that this property is overwritten. In Java you also
sometimes call a method that changes a global variable.
e.g. <target name="counter-plus-plus" description="Increment the
property counter">...
>>
>> 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.
From the javadoc of AntMain.java
* Interface used to bridge to the actual Main class without any
* messy reflection
And I personnaly did it, it wasn't too messy.
>
>> - 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?
The same behaviour as today, if they try to use these task without using
a third library ClassNotFoundException.
Note that because there were too much files in ant lib I couldn't run
ANT on Eclipse(Win2000).
>
>> - 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.
Can you elaborate? I don't understand what you mean.
>
>
> 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.
>
Ok here is a build file that would use the features I mentioned. Try to
translate it to a current Ant task and it will be probably less readable.
<project dir="." name="demo">
<target name="ask name">
<echo message="--- starting ask name ---"/>
<input message="Please enter db-username:"
addproperty="db.user"/>
<antcall target="define-db-user" keepProperties="true"/>
<echo message="The database user is now ${db.user}"/>
<echo message="Youpie superuser!!:" if="superuser"/>
</target>
<!-- useful target that I'd like to use apart -->
<target name="define-db-user" description="define the database user in
the db.user property">
<condition property="superuser">
<or>
<equals arg1="${db.user}" arg2="anthony"/>
<equals arg1="${db.user}" arg2="su"/>
</or>
</condition>
<property name="db.user"
value="superuser"
overwrite="true"
if="itsme"/>
</target>
</project>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ANT 1.7 features suggestion
Posted by Steve Loughran <st...@iseran.com>.
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.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ANT 1.7 features suggestion
Posted by Stefan Bodewig <bo...@apache.org>.
I'm soo late for the party that I'll try to not restart the whole
thing.
On Tue, 04 May 2004, Anthony Goubard <ad...@chello.nl> wrote:
> 1) Integrate if and unless at the Task level.
A nested <condition> would be far more powerful, as would be an <if>
task. Don't expect any opinion from me. 8-)
> 3) Regexp conditions
SMOP.
If anybody wanted to code them up (using Ant's regexp engine
abstraction layer, of course), I'm sure there wouldn't be any
objections.
> 4) Add an "overwrite" attribute at the property task. Properties
> are immutable but sometimes I think that you would like to change a
> propety.
I don't think this would be a good idea since immutability is
something that the parent build file relies upon and adding the
attribute would give the child build file control over it. An
overwritable attribute that the parent could set would be more inline
with the intent of Ant (why properties are immutable). Not that I was
advocating it.
Most cases where you've used <antcall> with <param> can be replaced by
<macrodef> and your "need to be mutable" properties become attributes
that way. I've found that this addresses most needs for mutable
properties at the same time.
> 5) Merge some jar files
Would defeat the reason why we've split up optional.jar in the first
place.
> - 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,
Some of our users run Kaffee with the swing classes for Java 1.1 from
Sun. You may want to load the swing lib via a different classloader
than main Ant. Same for TraX/Xalan and any JDK < 1.4.
> 6) Get the properties from a target after antcall
Would immediately break tons of builds that rely on throw-away
properties during <antcall> if it became the default. You probably
wouldn't want to keep all properties anyway, just a few of them.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org