ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stephan beal <>
Subject Fwd: DO NOT REPLY [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list
Date Tue, 26 Mar 2002 15:01:33 GMT
Erik's notes:
------- Additional Comments From  2002-03-26
 13:39 ------- Now do you understand why I feel uncomfortable re-using
 "tasks" internally?  :)

I'm marking this as WONTFIX as its by design.  Its for the case where you
 have a nested <include> and use the 'includes' attribute - so it *must* be
 this way.


But more importantly, perhaps discuss your needs on ant-user or ant-dev on
 what you're doing that can't already be done.

Refactoring would involve fixing PatternSet to follow it's published API. :/

Basically, here's what i'm trying to do: jar multiple jars with one task, 
re-using the same Jar task object on each loop . No problem. It works with 
very little code, except that the calls to setIncludes() and setExcludes() do 
not "set" anything - they append the values to an internal list. Thus when my 
second jar is jarred, it (incorrectly) has the includes/excludes from the 
first jar because the call to setIncludes/Excludes "doesn't work."

Forgetting subclassing, it makes the object unusuable in a delegation 
context except for the most basic of approaches (recreate/reconfigure object).

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).

In this case any changes must be done in PatternSet - Jar extends Zip which 
extends MatchingTask which extends Task (so much for not subclassing or 
re-using tasks internally, eh? ;), but ultimately the bug is in PatternSet. i 
could refector Jar/Zip/MatchingTask til i'm blue in the face, but that 
wouldn't solve this problem.

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 

----- stephan
Generic Unix Computer Guy -
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

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

View raw message