On 1 Mar 2002, Stefan Bodewig wrote: > > None of my proposals are touching class loaders directly > > I am aware of that, you said so in a separate mail. You just > shouldn't even mention them to support your changes 8-)
I prefer full disclosure, and besides most people can figure that for themself :-) > > That raises another proposal - enhancing the current ProjectHelper > > to be namespace aware is trivial - but will require SAX2. > > I know, it's just that I've never come around to doing it myself and > you promised to do it while refactoring ProjectHelper. Yes, the only big change in ProjectHelper is to change the signatures to use SAX2. The issue is how to pass/use the ns info - and that's where TaskFactory helps ( they are separated proposals, but help each other ) I am planning a bigger refactoring of ProjectHelper ( merging it with xmlmapper and some ideas from axis deserializer ), but that's not for 1.5 and will probably be in commons. ( I'm still at design stage, did few experiments but I'm not yet happy ). > One of my goals with name space support is that we can start to ignore > certain namespaces (those that we do not understand) so people can > extend Ant's build file syntax to to additional things in the build > files. +1 Again it's something that can be fine-tuned with the TaskFactory, but ignoring seems the best default for unknown ns. Unqualified names should remain reserved for ant1 tasks. > Think embedding gump project description in the build file for > example. Adding extra documentation inside the build file. Adding > information for a build file writing GUI. ... In addition, namespaces should be used to group optional tasks ( and even for core tasks ). But the current 'flat' model must remain the default for backward compat. > > - it must have 'valid' arguments. Anyone can challenge the validity, > > and that requires a second opinion > > Oh, I see where you get your second -1 from. That's not been my > understanding of valid, but I guess a seconded explanation has to > count as valid. Both the 'veto' and the 'invalid veto' can be abused - this seems like a good compromise and I'm pretty sure this is the rule. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
