> From: Costin Manolache [mailto:[EMAIL PROTECTED] > > If we want the description to apply to the _project_ and not > to the task - > then I agree, there is no way to implement <description> as a > datatype.
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. 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. > > 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. > I don't think this is a show-stoper for the HEAD - it'll have to be > fixed before the first beta, and I'll like to think more about it. > I agree, this should not be a showstopper at all. Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
