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 Tue, 09 Jul 2002 19:48:31 GMT
At 07:46 AM 7/9/2002 -0700, wrote:

>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.
>Of course, any proposal needs to start by saying that whatever was
>before is broken and can never be fixed. 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 :-)
>I still have to see one real issue that can't be resolved by
>the current codebase but can be by a proposal.

For most situations, I think you are absolutely right. In general, 
extreme-style refactoring is an excellent way to ensure you always have a 
working system while incrementally moving to the architecture you need.

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.

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.

I think one of the biggest concerns in deciding to adopt either of the 
proposals is that, once Ant 2 is released, it will have the same extreme 
backwards compatibility requirements that Ant 1 now has. Everyone wants to 
make sure the next codebase is one they can live with since they won't be 
able to make many fundamental changes, and there are differing views on 
what that would be.

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.

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

View raw message