Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 70069 invoked from network); 27 Mar 2002 06:38:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Mar 2002 06:38:10 -0000 Received: (qmail 17427 invoked by uid 97); 27 Mar 2002 06:38:18 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 17410 invoked by uid 97); 27 Mar 2002 06:38:18 -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 17394 invoked from network); 27 Mar 2002 06:38:17 -0000 From: "Adam Murdoch" To: "Ant Developers List" Subject: RE: DO NOT REPLY [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list Date: Wed, 27 Mar 2002 16:34:47 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > -----Original Message----- > From: stephan beal [mailto:stephan@einsurance.de] > Sent: Wednesday, 27 March 2002 1:02 AM > To: ant-dev@jakarta.apache.org > Subject: Fwd: DO NOT REPLY [Bug 7482] - PatternSet.setIncludes() does > not SET includes, but appends them to a list > > > i'll look into refactoring it, but i cannot imagine that i can make any > significant changes to PatternSet without a very high risk of breaking > something - there may very well be objects out there which depend on this > broken behaviour (and it is indeed broken, even if the break is only the > misnamed function: setX() should *set* X, not append it, unless the API > explicitely states otherwise). It's not broken. Unfortunately named, yes. But this behaviour is by design, and is a pattern you will find all over the Ant 1 code base. It's due to the naming scheme used by IntrospectionHelper to figure out how to configure an object. The places where you'll see setX() methods appending, are those classes which are used as data types, and which allow a nested element and an attribute of the same name (or usage). That's what you're seeing with PatternSet - which supports an 'includes' attribute, and nested elements. The setIncludes() method handles the 'includes' attribute, and has to append to the includes list, because it is called *after* the addInclude() method has been called. This is just the way it works. It's due to a core behaviour that isn't going to change in a hurry. Let it go. Why you can't create a new Jar object for each iteration? Or use ? > > Alternately, i could change MatchingTask.setIncludes() to clear > the list if > passed null? While i honestly cannot imagine that anyone depends on the > existing behaviour, i'm not sure enough about it to try to change that > behaviour. > The existing behaviour is used in cases like the following: If you really, really want to clear the set of includes, then add a method that explicitly does so, rather than overloading setIncludes(). Adam -- To unsubscribe, e-mail: For additional commands, e-mail: