ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: TaskAdapter/TaskFactory/RuntimeConfigurable
Date Fri, 01 Mar 2002 17:11:57 GMT
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.


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.


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

View raw message