ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: Delayed element creation implementation
Date Fri, 13 Dec 2002 22:14:20 GMT
Jose Alberto Fernandez wrote:

> My point here is that <description> is not something that should be
> executed like a <task> or <datatype>. It needs to be eveluated at
> loading time, irrespective of whether the <project> is actually build or
> not.

I actually have 2 different issues:

1. <description> inside <target> should apply to the target, not
project. ( and be concatenated with the description attribute ).
I can't see any reasonable argument ( besides "that's how it worked by
accident" ) for the counter-intuitive behavior we have now. The ant
manual doesn't even mention that you can have multiple
<description> and they'll be concatenated.

2. Description as a "special" case. You are right - description is 
not a task nor a datatype, and we'll need code to support it explicitely.
But I think we should keep the number of special cases to a minimum, and
avoid adding more things like Description.

I'm working on an implementation of Description outside of ProjectHelper,
and it is possible to have more classes that take a project tree
and walks the UnknwoneElements and does something. But this shouldn't
be mixed with the normal execution model, and we shouldn't abuse this.

> The fact that it was originally implemented as a <datatype> was just
> because datatypes happened to have this behaviour on this particular case.
> But is was just a cute idea based on many assumption about the execution
> model.

I know. 

>> Implementing it in ProjectHelper is IMO the worst possible choice.
>> ( the SAX parsing code should stay simple, and we loose the ability
>> to use ant without having to do the XML parsing, but directly
>> via API ).
>> What I'll try is to make description similar with <import> ( in the
>> sense that it'll walk the tree at startup ), and also
>> "load-on-startup"
>> ( so it'll be called even if there's no top-level description tag ).
> I do not know how <import> particularly works, but if the parser (or
> something) needs to recognize <import> and treat it diferent than say
> <echo>, then yes this is exactly what I meant. Is it possible to redefine
> <import> using <taskdef> to be something else? Would that make the parser
> stop treating <import> specially? If the answers to any of the above
> questions is NO, then we are treating these elements as syntactic
> elements.

<import> is not treated differently from echo and it can be <taskdefed> to 
something else ( from parser perspective ). There is nothing special in it.

It is similar with <description> and different from <echo> and regular
tasks - because it operates on the Project tree ( it reads a separate
xml file and inserts it, and it can rename some targets and change
dependencies ). Most tasks are not aware of RuntimeConfigurable or

All this happens _after_ the project is read and the tree created,
with no special action from the parser.


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

View raw message