ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: DO NOT REPLY [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list
Date Wed, 27 Mar 2002 06:34:47 GMT

> -----Original Message-----
> From: stephan beal []
> Sent: Wednesday, 27 March 2002 1:02 AM
> To:
> 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 <include> 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 <foreach>?

> 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:

<jar includes="some-pattern">
   <include name="another-pattern"/>

If you really, really want to clear the set of includes, then add a method
that explicitly does so, rather than overloading setIncludes().


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

View raw message