ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: ProjectComponentHelper and adapters
Date Sat, 09 Mar 2002 15:59:53 GMT
On Sat, 9 Mar 2002, Jose Alberto Fernandez wrote:

> Ok, I should sound like a broken record by now, but how do you plan to solve
> the case of data-types that DO NOT EXTEND from o.a.t.ant.types.DataType?

I allways have problems explaining - I answered this several times before,
it is a non-issue - we already do that for tasks that do not extend 
o.a.t.ant.Task, it works reasonably well ( I have few dozen tasks of this
kind ).

All you need is an adapter - for tasks we use TaskAdapter, something 
similar will be done for DataType.

The factory returns either a Task or a DataType. If the component 
implements the interface, no problem. If not - we return a TaskAdapter
or DataTypeAdapter, implementing the interface and wrapping the non-ant 

By extending the use of RuntimeConfigurable, the adapter can even 
implement arbitrary policies for 'adaptation' - you can adapt
an object that doesn't even follow ant patterns of setters, or 

Sorry for not beeing very clear in my explainations. 

> > For consistency, we should have all tasks use the RuntimeConfigurable,
> > even if they are top level - but that's again a change in the 
> > xml processor, can be done outside.
> Somebody else mentioned that maybe we should be using UnknownElement or 
> NestedElement all the way during construction and delay the actual expansion
> to just before usage (or when someone actually tries to access the Task out of the Target.

I would consider UnknownElement and NestedElement more of an internal for 
the helper. But if we need to - we can use them as well.

> The only special case is with "id" references that would have to be resolved when they
> are used, (if not resolved yet).

Doesn't seem like a huge problem.

> If we could a consensus on how to do that we could reduce ProjectHelper cruft by at least
> 80% (at least in the version in <antlib> proposal) and we would finish with a completely
> regular set of rules for constructing and evaluating the tree. And all that could be
done in a real
> backward compatible way. And yes we could get rid of all those invalidation tables in
the code.

It seems 'consensus' is not very easy - that's why making the core more 
flexible ( by adding hooks and modularizing ) is so important. If we add 
the right hooks, the consensus will not matter that much, any solution
will be implementable without requiring consensus ( as an external
plugin ), and if successful it'll be much easier to make it
part of the core. 

And will allow the various ant2 features to be implemented and used
with ant1 - so we can have a gradual transition, decide which 
implementations we want and which features are indeed usefull. And 
when we have everything, we can bump the version number and remove
deprecated stuff.


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

View raw message