ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Ant 2 et al.
Date Tue, 09 Jul 2002 16:49:09 GMT
On Wed, 10 Jul 2002, Conor MacNeill wrote:

> > Adding namespace support in ant1 is perfectly possible, as you know.
> > There is a working PluginHelper in proposals, that works with
> > ant1.5.
> >
> Adding namespace support is not a backward compatible change, though
> <project name="test" default="test">
>    <target name="test">
>      <taskdef name="test:echo" 
> classname=""/>
>      <test:echo message="hello"/>
>    </target>
> </project>
> Of course this is a contrived example but it illustrates just how 
> limiting the backward compatibility requirement really is. So sorry, no 
> namespace support possible.

Is there any project in jakarta, built by gump, that uses this construct ?
It seems most agree that 'build all that gump does' is acceptable
backward compat.

But even if some project uses this, it is trivial to use a command
line option to use ProjectHelper instead of ProjectHelper2. 

If we want to support namespaces in a future version of ant - I would
argue that any implementation ( including mutant/myrmidon ) would
brake this. 

> > My point is that ant1 architecute is one of the best, there is nothing
> > fundamentally wrong. And from looking at both proposals, I believe
> > they add complexity and I don't think the result is better.
> Encapsulation is fundamental and Ant1 does not have it, severely 
> complicating evolution. Nevertheless I do not hope to change your mind.

Not sure what you mean by 'encapsulation'.

If it is indeed something usefull, and we agree on that - is there 
anything to prevent adding it to ant1 ?

> I identified what was wrong with Ant1. There is no point proposing a 
> change unless you have issues with the current system. If you think the 
> current system is cool maybe you should hang out on ant-user. Putting 
> all jars in ANT_HOME/lib is not my idea of a good system.

And that's what antlib can solve. For most tasks it is already possible
in ant1.5 to define classloaders and taskdef using those loaders.


> > Most revolutions I know
> > are far for perfect, and some were far worse than what it was
> > before ( I'm thinking about general history here, not jakarta :-)
> So, some revolutions are necessary and liberate people from the yoke of 
> tyranny :-) (Not thinking of Ant1, of course)

I lived almost 20 years 'liberated' by a red revolution.  

> > I still have to see one real issue that can't be resolved by
> > the current codebase but can be by a proposal.
> Sure you can do anything in Ant1. But it is harder than it has to be. 
> Want to build a GUI, sure just pop in your own parsing code. Want to 
> reuse the copy task outside ant, grab project, project helper, etc, etc. 
> Give me polymorphism, run me a task which uses a different XML parser 
> from that used by Ant, etc, etc.

I already use ant tasks outside ant, and is not that difficult. 
It can be simplified - and I hope this will happen in ant1.6, but it
works fine. 

> For me the question has become whether it is worthwhile continuing to 
> develop Mutant at all. If the broad consensus of the committers is to 
> continue along the Ant1 evolutionary path then lets just say so. There 
> is a lot of committers from whom nothing has been heard on these threads.

I think it is worthwhile continuing to develop Mutant as long as 
you want to try new ideas. But hopefully Mutant and myrmidon ideas
will be reviewed and integrated into the main branch, and maybe
after 3-4 releases we could have a 2.0 with a new core, based 
on the ideas from mutant and myrmidon.

You can take a look at tomcat5 for example ( the proposal was
just aproved ).


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

View raw message