Erik's notes: ------- Additional Comments From [EMAIL PROTECTED] 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. Refactor! 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 behaviour. ----- stephan Generic Unix Computer Guy [EMAIL PROTECTED] - http://www.einsurance.de 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
