Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 86755 invoked from network); 10 Jul 2002 00:38:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 Jul 2002 00:38:12 -0000 Received: (qmail 8707 invoked by uid 97); 10 Jul 2002 00:38:27 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 8690 invoked by uid 97); 10 Jul 2002 00:38:27 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 8678 invoked by uid 98); 10 Jul 2002 00:38:26 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-Id: <5.1.0.14.0.20020709142718.04b12778@orson.callenish.com> Date: Tue, 09 Jul 2002 17:38:21 -0700 To: "Ant Developers List" From: Bruce Atherton Subject: Re: Ant 2 et al. In-Reply-To: References: <5.1.0.14.0.20020709120149.03df3d30@orson.callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 02:02 PM 7/9/2002 -0700, costinm@covalent.net 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 >overengineering. Ahh. So the issue is how they are implemented rather than whether they are rewrites? >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: