Erik Hatcher wrote:
> Bruce Atherton wrote:
>>> Maybe there
>>> are things from the framework that could be leveraged to not have to
>>> recode
>>> everything, but I haven't looked.
>>
>>
>> You mean something that would provide IntrospectionHelper-like abilities
>> inside setDynamicAttribute() and createDynamicElement() so that it
>> automatically called the right methods on the newly-loaded class? That
>> sounds interesting. Erik?
>
> Yes, definitely interesting. I thought about these issues when I
> committed DynamicConfigurator, but the tough issue is the lookup of
> element name to its corresponding class - some kind of registry. If
> your or DD have ideas on how this could be done elegantly and
> generically then I'm all for it.
Adding a hook is quite easy. You just need an interface and a helper
class that will deal with registering hooks and calling them.
It's quite easy to move any piece of processing from 'core' to
a hook chain. And for almost everything it can be done not only in
a backward compatible way, but also pluggable in the stock ant1.5
( if you use an embed-like aproach of replacing the ProjectHelper ).
One of the things I would like to propose ( real soon ) is the
ProjectComponentFactory/ProjectComponentHelper hook for locating
tasks. That should allow any kind of antlib policy to be implemented
for 1.5 and 1.6.
Another hook I'm lobying for deals with replacement of ${properties}.
I'm experimenting with a more advanced one that would allow
"${ref:reference}" to actually call a setter using the real
reference type ( foo="${ref:a} -> setFoo( Bar param ), where 'a'
is a reference to a Bar type ). That would require hooking into
IntrospectionHelper - and I can tell you it's not very hard.
> Have a look at the 1.2 version of XDoclet -
> http://xdoclet.sourceforge.net/1.2beta/ - its got a pretty slick module
> facility to dynamically load subtasks and tag handlers. Subtasks use
> the DynamicConfigurator mechanism. You can simply drop in a JAR that
> has the right metadata XML files embedded in its <taskdef> classpath and
> it will auto-discover them and make them available.
I'll take a look. I was thinking to use commons-discovery to locate the
manifest - but there are many other solutions.
> I have not had a chance to look into the embed proposal but I believe it
> shares this same goal of antlib and a more pluggable architecture.
More pluggable - yes ( it's mostly a set of hooks ). I prefer to see
antlib as a 2-layer: one is the hook into task creation, the other
is the actual discoverer/manifest/whatever implementation.
> I'd be all over some type of merging of all these ideas including
> folding some of the Myrmidon concepts relating to this.
And Mutant and the proposal/sandbox/embed :-) +1 from me.
--
Costin
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|