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 UnknownElement. All this happens _after_ the project is read and the tree created, with no special action from the parser. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
