ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Goubard <adagoub...@chello.nl>
Subject Re: ANT 1.7 features suggestion
Date Tue, 04 May 2004 21:39:51 GMT
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


Mime
View raw message