From: "Stefan Bodewig" <[EMAIL PROTECTED]>
> > No point in asking for other committers feedback,
>
> Why not?
Well, I guess I did.... :))
> Using a reflection based implementation may have been superior over
> interfaces and if it only way so that people who want to put their
> stuff under GPL can use this functionality without violating their own
> license 8-).
I prefer the interface method and Ant should be defining the interfaces that
vendors adhere to - this gives us a tighter contract with vendors and forces
them to adhere to it to tightly couple with Ant. Seems like a win-win
situation.
> OK, seriously: I don't really follow the "pluggable attributes" use
> case, as you only save yourself from typing a couple of setter - and
> lose Ant's conversion service (for Files for example) as the price for
> it.
Yes, fair enough counterpoint, and one I had thought of myself, but figured
a task writer that wanted dynamic attributes would be willing to deal with
types on their own.
> Pluggable elements is a different story - of course all tasks that
> want to support such pluggability could do so now with some extra
> effort without needing the support you want to add to
> IntrospectionHelper.
>
> Something like
>
> <condition>
> <usercondition classname="...">
> <classpath ... />
> <param name="..." value="..." />
> </usercondition>
> </condition>
>
> could easily be implemented without your enhancement.
Agreed.
I think we should be making life easier for task writers rather than
tougher. I'm sure this is a common goal of the committers: create a more
open and extensible build tool so that Ant itself doesn't have to maintain
as many tasks as it currently does. The vendors should maintain them and
adhere to our contracts.
Given that the capability to dynamic stuff can already be achieved but in a
far clunkier manner, I don't see why it hurts to make it less clunky.
> What you propose just makes it simpler (and pushes part of the
> responsibility from tasks to the container), but it is not as if it
> would be impossible right now.
>
> I don't have a really strong opinion here, but I'm certainly not -1 on
> your changes.
Thanks.
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
