ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: PROPOSAL: top level execution order
Date Wed, 27 Nov 2002 16:54:41 GMT
Shackelford, John-Mason wrote:

>> Every opinion is important.
> Though some opinions are more important than others ;) I offer an
> indisputably unimportant one ;) :

I agree with the first part - all opinions that are sent to the list
and with arguments are more important than the others :-)

>> document this and explain the behavior
> I agree that to use javac, etc. as top level tasks is bad practice; but if
> it is allowed, it ought not break -projecthelp, etc.

It won't break -projecthelp - it's just a side effect that when you want
the list of targets you also execute a small compilation.

An "echo" at top level may be a bad thing or a good thing ( you may want
to display some extra information ). And I can imagine valid uses of javac
at top level.

> A fourth option--which I doubt will be acceptible to anyone--would be to
> limit top level tasks. This is probably not worth considering.

That's the behavior in ant1.5, top level tasks are not allowed in general.
I think it's a bad solution - our main concern should be to make things
possible, not to make things impossible :-). And preventing the user from
using ant the way he sees fit because we have a different use case is 
also bad.

> A fifth option which is which combines elements of all others (excepting
> #3) is to use a marker interface--or a different base class, etc.--to set
> aside a class of import-like tasks. These can then all be handled first.
> ProjectHelper becomes only a bit more complex, only these special case
> tasks are required to have the "marker", and import can remain a task all
> without breaking -projecthelp, etc. The downside here is that having two
> types of tasks could be confusing.

There are many problems with marker interfaces. I doubt they'll get 

Probably a middle-ground solution with some meta-data ( i.e. config ) 
could be accepted ( maybe this can be reopened when the format for the
standard antlib is discussed - I care more about adding the hooks
to allow pluggable task factories at this moment ). 

I prefer to encourage people on using TaskAdapter and regular beans
instead of extending Task whenever possible. The main power of ant
( IMO ) is the lightness of the core, for most cases you shouldn't
care about ant interfaces. I wouldn't vote for marker interfaces
if any other solution is possible.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message