Return-Path: 
 <ant-dev-return-36201-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 73250 invoked from network); 21 Jul 2002 00:52:01 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 21 Jul 2002 00:52:01 -0000
Received: (qmail 20398 invoked by uid 97); 21 Jul 2002 00:52:21 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 20379 invoked by uid 97); 21 Jul 2002 00:52:20 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 20362 invoked by uid 98); 21 Jul 2002 00:52:20 -0000
X-Antivirus: nagoya (v4198 created Apr 24 2002)
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Subject: Re: Backwards compatability?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_M13_04302002 Pre-release 2 April 30, 2002
From: dion@multitask.com.au
Message-ID: 
 <OF1E804FE7.A3C7C870-ON4A256BFD.00035EF1-4A256BFD.0004B2DE@multitask.com.au>
Date: Sun, 21 Jul 2002 11:05:53 +1000
X-MIMETrack: Serialize by Router on gateway/Multitask Consulting/AU(Release
 5.0.8 |June
 18, 2001) at 07/21/2002 11:06:06 AM,
	Serialize complete at 07/21/2002 11:06:06 AM
Content-Type: multipart/alternative;
 boundary="=_alternative 000365224A256BFD_="
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

--=_alternative 000365224A256BFD_=
Content-Type: text/plain; charset="US-ASCII"

Can't there be tests written for antcall to pick this up?
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


costinm@covalent.net wrote on 07/21/2002 02:27:11 AM:

> 
> > For instance, the changes in property inheritance between projects
> when you do 
> > sucessive project calls has broken a HUGE number of my build files. 
Almost 
> > universally I have a set of controller build files that in turn call 
worker 
> > build files that may in turn call other build files.
> 
> It's very unfortunate those were not discovered _before_ releasing 1.5.
> 
> IMHO this is a bug. 
> 
> We should fix it ( i.e. reverse the inheritance rules to 1.4 ) and 
release
> a 1.5.1 that fixes this problem, it is serious enough.
> 
> I tested all my 1.4 build files before 1.5 release, and Gump does a lot
> of testing - but it seems this one didn't show up. 
> 
> Bugs happen, there is no way to avoid them.
> 
> > To be honest I am getting very sick of updating the same ant filesover 
and 
> > over. Each release I have had to go through and make a large number of 

> > changes to builds to get things going again. I don't consider myself 
stupid 
> > or unknowledgable wrt Ant and thus I don't think it is a user error 
that is 
> > causing these constant incompatabilities.
> 
> +1
> 
> Good thing that at least we don't have to rename attributes in the build
> files.
> 
> 
> > What I want to know is how we plan to fix it in the future. With 
> our current 
> > "system" I am not sure there is a clean or elegant method via 
> which we can do 
> > this. The only thing that I can think of is versioning the names of 
the 
> > tasks.
> 
> No, there isn't. Testing is the only way to find bugs and regressions. 
> Maybe we can improve things - like make gump run closer to what the
> project wants ( i.e. without full CLASSPATH, etc ).
> 
> I partially agree with 'versioning', but the main goal should be to
> preserve backward compatibility and use versioning only when there's
> no way to keep backward compat.
> 
> 
> > For instance we upgrade <antcall/> in an incompatible way then itstask 
name 
> > would become <antcall2/> etc. To avoid the pain of maintaining 
> separate tasks 
> > we could do something similar to the following in each task that 
changed...
> 
> Or we add a an attribute to antcall to triger the different rules - with
> default to the old behavior, I don't think we need antcall2 in this 
case.
> 
> But the real question is if the new behavior is indeed that much better 
> than the old one.
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
<mailto:ant-dev-help@jakarta.apache.org>
> 

--=_alternative 000365224A256BFD_=--