Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 65270 invoked from network); 10 Jul 2002 16:35:34 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 Jul 2002 16:35:34 -0000 Received: (qmail 15414 invoked by uid 97); 10 Jul 2002 16:35:46 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 15397 invoked by uid 97); 10 Jul 2002 16:35:46 -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 15385 invoked by uid 98); 10 Jul 2002 16:35:45 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Wed, 10 Jul 2002 09:34:14 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Ant Developers List Subject: Backward compat ( was: Re: Ant 2 et al.) In-Reply-To: <3D2B7516.5020608@cortexebusiness.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 10 Jul 2002, Conor MacNeill wrote: > > Is there any project in jakarta, built by gump, that uses this construct ? > > It seems most agree that 'build all that gump does' is acceptable > > backward compat. > Wow - is that your definition of backward compatability? > It seems people talk up backward compatability until it gets in their way. It seems that's what ant-dev considers acceptable. My definition is a bit different - I'm strongly against 'cosmetic' changes, and most API changes ( there are enough ways to preserve the old APIs - by using new methods and aliases, up to facades ). If a change has clear benefits for most users - and the pain is reasonable ( and can't be easily avoided ) - I'm +1. You make me look like a fanatical who won't accept any change. I think my position is entirely reasonable, and few other people are using 'backward compatibility' argument in unreasonable ways. I do talk about backward compatibility when I see trivial cosmetic changes ( like jarfile/destfile ). Or when methods are removed/renamed even if it is trivial to preserve the old signature. Or when people talk about renaming to , just because it is 'cleaner'. Or when the Connection interface gets few more methods making it impossible to write drivers that work with JDK1.3 and 1.4 ( instead of just adding a separate interface ). This is totally different from breaking some build.xml files that are invalid under the current XML spec - with the benefit of adding namespace support and solving the naming issue and possibly making the whole thing easier to use. I hear the claim that 'it is ok for ant2 to break compat, but nothing can change in ant1'. Well, compare ant1.0 with ant1.5 - it seems all 1.x releases except the last had incompatible changes and would fail the gump test. I'm pretty sure even with 1.5 we can find some extreme cases where things will brake - but overall I think the users will benefit greatly from the 'backward compat' arguments. And it was well worth the flames. The reasons I'm against both ant2 proposals is not backward compat - but the design, which I find worse than ant1. I did look at the code - and it screams "over-engineering" and "featurism". For most task developers there are 2 classes that matter - Project and Task. The XML APIs consist of 3-4 classes. It is possible to embed ant using 2-3 classes ( and if a cleaner API is needed, that can be done without major problems). Compare this with the forest of interfaces and classes in the proposals. If you want a framework - use one, don't turn ant into one. Do we need a clean ComponentManager interface - yes. But it can be easily added to ant1.6 - with Project methods calling it ( and 100% backward compat ). Do we need a Task interface? I don't think so, java beans are enough. I think we need to extract some of the things in Task, Project into separate services ( commons-like ) that can be used by tasks without having to extend Task and independently of ant. But all that can be done in ant1.6, ant1.7, etc - with reasonable backward compatibility. Of course - all this is MHO, and each step should be discussed until we're all comfortable with a solution. As oposed to get a package of pre (or over ) cooked solutions as a new codebase. > > If it is indeed something usefull, and we agree on that - is there > > anything to prevent adding it to ant1 ? > > backward compatability :-) I see. Using the definition that backward compatibility is broken by adding any usefull features to ant1 that would make mutant less usefull. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: