ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: Ant 2 et al.
Date Tue, 09 Jul 2002 12:16:59 GMT

On Tuesday, July 9, 2002, at 09:44 , Nicola Ken Barozzi wrote:

> Well, more than suggested.
> There is a working patch in bugzilla.
> Why not include or include-project?
> Dunno, there's no reason, call it smurf, it ok for me as long as it 
> smurf well ;-)

OK, <smurf> then :-). I had a quick look at the code although I have had 
other things on my mind recently. I saw you have extended the 
inner-class nightmare that is currently there. I'm not a fan of that 
code (I refactored it in Mutant).

>> In 1.6 Stefan will enable top level tasks.
>> But, if someone has their own <import> task, they can't use it at the 
>> top level since you will effectively introduce a new keyword to Ant. 
>> Mutant tries to solve this problem by using a namespace for this sort 
>> of metadata. I believe Myrmidon uses a task for <include> although 
>> there are issues with that approach which I'm not sure how they have 
>> addressed.
> Is mutant based on Ant or a complete rewrite?
> Because in the first case, it maybe can have pieces put into Ant 
> progressively... I'll look into the code again, it's a while since I 
> did it.

It is a rewrite. It is based on many of the ideas of Ant1 but if you 
want to clean up some of the issues in Ant1 (the excessive coupling of 
Project class, for example) you must rewrite.

>> Anyway, my point is that it is probably easy to grab features from the 
>> proposals but without the underlying architecture, the result may not 
>> always be that good.
> May.

Sure.  There are probably some features of Mutant, and possibly Myrmidon 
that could be simply back ported to Ant1.

> Let's say I grab features progressively.
> Say again that I reach a point when Ant1 is in 1.9, really close to the 
> proposals.
> At that point, switching the underlying architecture would make no harm 
> to users, and it would be good.

The real feature of Mutant is the "underlying architecture". The more 
you build on the shaky foundation of Ant1's codebase, well ...

>> Let me give an analogy. You live in the leaning tower of Pisa and you 
>> see your neighbours are adding rooftop pools to their building. They 
>> look pretty cool but putting one on your roof may leave you a little 
>> wet :-)
> ;-P
> My impression is that my building can still get features till it 
> resembles the neighbours'.
> But then, the neighbours can make theirs better still, while I can't.
> Only then I decide to use their building, now that I'm accustomed to 
> living in something like it :-)

Let's hope it doesn't fall down.

Already I have seen cases where Mutant would work in a situation where 
Ant1 did not. The requirement for Ant1 tasks to preserve their config 
state was not being met and causing problems in the zip task. It is only 
the herculean efforts of Stefan to check all tasks that keeps this at 
bay. Unfortunately the resulting code is harder to understand and 
maintain. (Check out the zip/jar code for all the savedState variables).

It's one layer of spakfilla on another.


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

View raw message