ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: IntrospectionHelper request
Date Thu, 10 Jan 2002 13:14:15 GMT
----- Original Message -----
From: "Peter Donald" <>

> Im not disgreeing with the need but as I said I disagree with the method
> consider it a workaround for limitations in Ant1.x model. The
> lookup/registry/factory etc for new implementations of interfaces should
> be done by the task but should be done by the container.

I'll have to ponder the container needing to do the lookup rather than the
task since the method of lookup desired may be different between tasks....
some might want JNDI lookup, and others via properties files.  Your proposed
container would allow for this extensibility?

> They are workarounds for ant1.x failings and thus I don't consider them
> usecases at all ;)

But how long are we going to be using Ant 1.x?  When will Ant2 (1.9?) be
released?  Why should <ejbjar>/XDoclet, and others have to live in agony
until then when my patch alleviates it until the new architecture is

It doesn't break backwards compatibility and only will enhance new tasks
that desire to take advantage of it, not hurt older tasks.  Isn't it
detrimental to Ant's progress to not allow extensibility within our current
architecture just because its not perfect and needs overhauling in the
future?  I realize that Ant2's (1.9?) architecture is dramatically different
and the best route from here to there is to gut it and start from scratch in
a lot of areas, but why restrict Ant1.x's progress just because something
better is in the works?

I assume we'll have an Ant 1.5 release in the near future.  With this kind
of extensibility capability it could perhaps extend Ant 1.5's lifespan and
reduce the number of Ant 1.x releases we need to get to Ant2 - and we as
committers could devote more attention to the new architecture.

We had this very issue just crop up with the JOnAS patch:

With <ejbjar> refactored to implement DynamicConfigurator, this would not
have been an issue at all.

> > Seem reasonable?
> no ;)

*arg*  :))   *shrug* - I don't get it.  *sigh*

Are you -1'ing my enhancement?  Or just -0?  I've given my best examples of
use-cases, so time for a decision I suppose.  :))


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

View raw message