ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/helper
Date Tue, 30 Jul 2002 16:51:12 GMT
On 30 Jul 2002, Stefan Bodewig wrote:

> On Wed, 24 Jul 2002, <> wrote:
> > But I think what we should fix is -projecthelp
> How can you fix it?  You'd still need to execute <import> if you want
> to list the imported targets as well, don't you?


I think we have requirements that can't be all satisfied, and
we have to decide on what we can give up.

1. Import. In order for this to work corectly ( and -projecthelp
to report all targets, including imported ones ) it clearly needs
top-level tasks to be executed for projecthelp.

2. Arbitrary top-level tasks. If <javac> is used at top-level,
then executing top-level on -projecthelp will lead to undesirable

My proposal is to execute top-level before target dependency,
including in the case of -projecthelp. That favors import over
arbitrary top-level tasks.

We can add some extra tests - for example if the <project> has
no default target or has some special attribute it'll be a
target-less project and we'll not execute the top-level tasks
in -projecthelp case ( and in ProjectHelper ).

What do you think ? 

> > and make clear that whatever is at top level will be executed after
> > the xml file is read, regardless of the target name to be executed.
> Not nice IMHO.

If the current practice of 'property and non-action tasks' is 
preserved, this will work ( the same as it works in 1.5, where
top-level is executed in all cases during the xml reading ).

> > And we should recommend that only 'initialization' tasks 
> > should be at top level
> +1 - together with some examples of what we consider "'initialization'
> tasks".  My list would be all property setting tasks as well as
> taskdef and typedef.  Others?

import  :-)

And any other 'meta-task' that affects the project structure - 
it can be custom task as well. ( that includes 'extend', 'include',
etc ).

> > - however I don't think we should enforce this too strongly,
> Can we at all?

We have a range of options - from hardcoding the allowed tasks
( the current solution in 1.5 ) to marker interface to 
complete freedom and let the user decide.

Probably the best solution would be to make a list of all
options and ask for a vote - it's very much a matter of taste
and I suspect no technical argument can settle this. 


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

View raw message