ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
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, <costinm@covalent.net> 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 
ProjectComponentHelper.

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.

Costin
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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message