ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: ProjectComponentHelper and adapters
Date Wed, 13 Mar 2002 15:51:37 GMT
On 13 Mar 2002, Stefan Bodewig wrote:

> On Fri, 8 Mar 2002, <> wrote:
> > Ok, everything can be done with no code change in
> > RuntimeConfigurable except making some fields protected.
> Or add accessors instead of touching the attributes directly.

Adding accessors would be my preference. 

If we do so, I would prefer using xml-independent accessors - 

  addAttribute( String name, String value );
( or ns, name, value )

instead of AttributeList/Attributes. 

Having the core depend on sax1 is not very clean, so I would
deprecate the use of sax1 attributes.

Of course, the current interfaces are easy to support for
 backward compat, just stop using them in new code. 

> > It's pretty smart code, I'm impressed
> Well, I've certainly heard different statements, but UnknownElement is
> the worse of the two, I agree. ;-)

Yes, but UnknownElement can be avoided by using the 

AFAIK the main purpose for UnknownElement is to deal with tasks that
can't be constructed at runtime ( for example they are taskdef-ed 
in a target ).

The default ProjectComponentHelper may treat them in the same way as
'external' components, and use the task adapter - which can delay the
construction of the object if it wants to. I'm not talking about the
current TaskAdapter, the ProjectComponentHelper may return different
subclasses - I think the ProjectComponentAdapter should be just 
a base class ( even interface ), so we move more functionality 
out of core and into plugins. 

> > For consistency, we should have all tasks use the
> > RuntimeConfigurable, even if they are top level
> What would you gain by this change?  The top level tasks will be
> executed immediately anyway.  Or do you propose to defer the execution
> until parsing has finished?

Consistency ( and simpler code ) in the xml processor. We can't 
defer the execution - that would change the behavior, the default
must remain backward compatible. 

But I'm not saying we shouldn't support defered execution, or any
other feature that may be interesting - just that the default
should be what we have, and the core API should permit anything.

P.S. I'll have little time this week, I have the changes required
by Connor on ProjectHelper and a bit more code on the component
helper, but I need more tests.

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

View raw message