ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: ProjectComponentHelper and adapters
Date Sat, 09 Mar 2002 09:02:34 GMT
From: <>

> On Fri, 8 Mar 2002 wrote:
> > I think I found a good solution for dealing with 'non-ant' tasks
> > and types ( the adapters ), with the minimum amount of change.
> Ok, everything can be done with no code change in RuntimeConfigurable
> except making some fields protected. 
> It's pretty smart code, I'm impressed - the task is creating the
> wrapper, so it can return a class that extends RuntimeConfigurable.
> The only problem is for data types - where 'new RuntimeConfigurable'
> is hardcoded in helper and it has no hook.
> Moving getRuntimeConfigurableWrapper() to ProjectComponent ( or 
> adding it to DataType ) and making few fields protected is the
> only change that is needed in core ( besides adding the factory 
> to create tasks/data types ). The xml processor will need
> changes, but it is a plugin already. 

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?

> 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.

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

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

Jose Alberto

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

View raw message