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.
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.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.
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.
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.
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.
<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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
