Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <879A5AD5DD0ED511891F0003473A9B560E23F099@Z011004>
From: Jan.Materne@rzf.fin-nrw.de
To: dev@ant.apache.org
Subject: RE: ANT 1.7 features suggestion
Date: Wed, 5 May 2004 10:02:07 +0200 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>  1) Integrate if and unless at the Task level.
> This would allow all ANT tasks to have the if and unless=20
> attribute (the=20
> same way that it has an id attribute).
> So far the only way to do it is by using <target> except if=20
> you use one=20
> of the task which has already the "if" "unless" attributes=20
> such as <fail>.
> I think ANT users would use this feature to remove some=20
> tartget created=20
> only for the purpose of the "if" or would remove the=20
> ant-contrib <if> task.
>=20
>  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=B4ll 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".=20
Then we=B4d 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=3D"${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=20
> also extend=20
> the <equals> and <contains>

is ok.


>  4) Add an "overwrite" attribute at the property task.
>  Properties are immutable but sometimes I think that you=20
> would like to=20
> change a propety.
>  The way to do it is to use <antcall> with <param>, now you would be=20
> able to redefine an property with overwrite=3D"true".

I wouldn=B4t merge the immutable/override theory ... If a user sees a
property it should be immutable.=20
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=20
> proposition to reduce the number of jar files:
>   Remove ant
>   - Remove ant-launcher.jar and integrate the classes to=20
> ant.jar, this=20
> would also imply that the loading of the class Main is done using=20
> 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=20
> ant-nodeps.jar)
>   - put all J2EE tasks together
>   - all tasks that uses apache or open source in ant-osi.jar=20
> (ant-commons-*.jar, ant-apache-*.jar, junit, ant-jakarta-*.jar,=20
> 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=B4t 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 :-)=20

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

Regarding JDK 1.4 I aggree with Ken - I would prefer the 1.4 or 1.5, =
too.
But I=B4d 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=20
> necessary=20
> at the beginning or you may want to pass some parameters.
>   That's why it would be nice to have a "keepProperties" (or=20
> whatever)=20
> attribute to the <ant> and <antcall> task.


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


=20
>  Let me know if you want me to implement some of my ideas or=20
> report some=20
> 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=20
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org