On 30 Jul 2002, Stefan Bodewig wrote: > On Wed, 24 Jul 2002, <[EMAIL PROTECTED]> 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?
True. 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 results. 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. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
