ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: Ant 2 et al.
Date Wed, 10 Jul 2002 00:38:21 GMT
At 02:02 PM 7/9/2002 -0700, wrote:

>If we do accept breaking the API backward compatibility in future versions
>- that can be done with the Ant1 codebase as well.

Semantics. If you break backward compatibility it is Ant 2 to me. And as I 
said you could start from the existing codebase and start refactoring from 
there, but I don't understand what the advantage would be. Maybe it would 
end up being more compatible with Ant 1 than the other proposals, maybe 
less. We wouldn't know until the refactoring was done. At least with the 
current proposals we have some idea of the breakage.

>But I don't agree you need to brake backward compatibility in order
>to refactor - we can easily create a new core ( hopefully cleaner -
>which is not the case with the current proposals IMHO ) and
>then keep the old API as just a wrapper.

You could write a facade to the old API for any proposal, but impedance 
mismatches mean it isn't "easy" in any case. And the more design choices 
that are co-opted in order to maintain compatibility with the old API, the 
less Ant 2 can meet its other goals. If we have to introduce 
incompatibilities, we should do our best to introduce them all at once and 
get it over with IMHO.

>The problem is not to get a proposal in a running state. It is to make
>sure the proposal is what we need.

I hope you'd agree that getting into a running state is ONE of the 
problems. :-) The fact that these proposals are already there gives them a 
big leg up on any hypothetical solutions.

>Both proposals have a huge amount of changes that will get in with
>very little review and discussion. That's a serious problem for me.

What makes you think either one would be adopted with "very little review 
and discussion"? They've generated a fair amount of discussion in the past, 
and I'm sure there would be much more before a codebase change was decided 
upon. As for review, several people here have mentioned that they are going 
to get more familiar with the proposal code soon. I'll add myself to that 
list. I know I wouldn't cast a vote for adopting either one until I'd 
reviewed both of them more closely.

>And at the moment, they both suffer (IMHO again ) from serious

Ahh. So the issue is how they are implemented rather than whether they are 

>For modularization and reuse - there are plenty of solutions that can
>be done in ant1. Adding namespace support is one part, and
>I think it can be addressed in ant1.6 ( it already works with ant1.5 ).
>Antlib is the other part.

And this will stop you from getting the whole gorilla when all you want is 
the banana?

>I don't know the details of the PatternSet problem, but even if there
>are problems, we must put in balance the amount of changes in the
>user build files to the benefit of making a change.

This is at the heart of the issue: tradeoffs. Ant 2 will impact some users 
by definition (at least by my definition). The question is, how much impact 
are we willing to subject users to in order to get a better architecture 
that will ultimately give users a better experience and reduce the 
maintenance burden on us?

If you feel that Ant 2 won't have a better architecture, as you seem to 
about the current proposals, the answer is "Not very much".

If I understand what you are saying, your alternative proposal is, 
"Something derived from the existing Ant 1 codebase. What that something is 
we don't know yet. How much it will end up diverging from the existing 
codebase we don't know yet. But it should be simpler and more compatible 
than either of the current proposals while addressing similar goals."

Is that a fair restatement?

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

View raw message