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 21:02:14 GMT
On Tue, 9 Jul 2002, Bruce Atherton wrote:

> The reason that Ant 1 is an exception to this is because of the level of 
> backward compatibility that has to be maintained while refactoring. It is 
> far more extreme in this regard than almost any other project. Any public 
> class must be maintained in perpetuity. Any method that is not private 
> should be maintained, signature and all, although the implementation can 
> change. This approach is very beneficial for custom task writers, but it 
> puts a straightjacket on developers and the refactorings that are possible.

> The real reason Ant 2 is needed is because it allows us to break this 
> extreme backwards compatibility and go for one that is less intense. Yes, 
> Ant 1 build files should be supported or at least be convertible with a 
> script. Yes, custom tasks in Gump should either work as in Ant 1 or 
> replacements for them offered long before the Ant 2 release. But that is a 
> far lower bar than Ant 1 must meet.

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

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.

Tomcat5 proposal is doing exactly that ( whith the goal of 
having binary compatibility with both tomcat3.3 and 4.0 !). 

> So rather than using one of the rewrite proposals, should we just take a 
> copy of the Ant 1 code and start refactoring on that? Given the difficulty 
> of rewriting from scratch, I'd support that were it not for the fact that 
> we already have not one but two rewrites already completed (which is part 
> of the problem in moving forward). Thus there is no need to refactor Ant 1 
> to get Ant 2 to a running state, we are already there.

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

In the main trunk all code changes are carefully discussed ( look
at the antlib, or ProjectHelper hooks !) and they have to pass a very high 
bar. That's normal - we'll have to live with them and maintain them
for a long time in future.

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.
And at the moment, they both suffer (IMHO again ) from serious 

> As for the one real issue that the current codebase can't address (without 
> breaking Ant 1-level compatibility), I've already complained here about the 
> problems I had with PatternSet that could not be fixed without potentially 
> breaking compatibility. Then there are the modularization and reuse issues 
> others have mentioned. Believe me, there is a need for Ant 2.

I agree there is a need for ant2 - all I'm saying I disagree with the
procedure of getting there by swallowing a different codebase. 

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.

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. There are dozens
of broken things in the servlet spec - and sometimes they get
corrected ( if they affect security, etc ) but most of the time they
are preserved. Same for the JDK itself. I think ant must be 
at the same level.

The 'backward compatibility' rule is not written in stone - if all
commiters ( or all but 1 - using the 'valid' veto rule :-) agree 
something needs changed - it can be changed. 

The 'ant2 revolution' is just a way to replace consensus voting with
majority voting for braking backward compatibility. But what's 
really bad is that instead of having each change individually voted,
we'll have to vote on a boundle. 

If the voting is the issue ( i.e. we deadlock with 2 -1s blocking 
a change ) - we can still use a micro-revolution and use majority
voting to get past the issue. 


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

View raw message