Stefan Bodewig wrote: > Another downside of the HEAD version: As I pointed out last week, the > way CVS HEAD works breaks backwards compatibilty in a subtle way > because <taskdef>s will no longer be executed before the task > definitions are encountered by the parser right now.
That's an upside IMO :-) It will lead to more consistent behavior ( especially if combined with the generalised lazy eval ). If something relies on taskdef beeing executed imediately, then it's a bug since we have no guarantee on that ( the taskdef at top level will execute the same as a taskdef in a target ). That's if we're talking about the same thing :-) > On Tue, 26 Nov 2002, Costin Manolache <[EMAIL PROTECTED]> wrote: > >> The downside is that if tasks like <echo> or <javac> are used at top >> level, they will be executed when -projecthelp is called. > > And when the parser detects an error after some of the tasks have been > run ... Parser ( XML ) errors will be detected in the same way in the main build file. Parser errors in imported files - yes, but the same would happen if <ant> task is used. Non-XML errors and validation - yes, but that's exactly what can happen today in many cases. I agree - we'll introduce many new ways for users to hurt themself, but they never lacked that ability. >> Unfortunately it is not possible to implement -projecthelp >> and also allow <javac> _and_ allow import in a clean way. > > Not that I'd like any of the solutions too much: > > * marker interface for tasks to be run at parser time. That's a possible solution - however the biggest limitation (IMO) is that users may _need_ to execute all kind of stuff ( url get, etc ? ). > * implement <import> by something that is not a task. The reasons for import as a task: - simpler project helper ( it avoids complexity in a very tricky area) - cleaner implementation (IMO) Import is just one particular case - a whole class of tasks that operate on the project tree will be possible. >> The only solution is to document this and explain the >> behavior > > Third option, and probably the one I like most. But I still want to > wait a few days to see whether anybody finds yet another solution to > make that a fully supported +1. > >> Stefan - can you live with the top-level processing in embed ? > > My opinion is not that important, just one of a whole bunch of > committers. Every opinion is important. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
