ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list
Date Tue, 26 Mar 2002 17:25:25 GMT
How about adding a reset() or resetPatterns(boolean includes, boolean
excludes) method on PatternSet, that Stephan can call explicitly!?!?! That
way's everybody's happy, and a PatternSet instance can be reused to match
something else? Haven't looked at any code, but it seems that would work for
Stephan... --DD

 -----Original Message-----
From: 	Erik Hatcher [] 
Sent:	Tuesday, March 26, 2002 10:59 AM
To:	Ant Developers List
Subject:	Re: [Bug 7482]  - PatternSet.setIncludes() does not SET
includes, but appends them to a list

----- Original Message -----
From: "stephan beal" <>

> Before i start, let me say that i *know* my approach is non-canon. i'm
> trying something new here, and in doing so i found a problem with
> PatternSet.

No you didn't.  Don't confuse the "how task setters work when defining
patternsets" to a problem with PatternSet.  The only "problem" with
PatternSet that I've seen is that you can't nest them, which I will
implement soon.

> i need to jar different parts of our source tree into different jars - a
> total of about 15 jars. i could very well do that with 15 jar tasks, no
> problem. Instead what i've chosen to do is implement it like so, in
> properties:
> my.jar = de/einsurance/foo/**/*,de/einsurance/bar/**/*
> my.jar.exclude = de/einsurance/foo/test/**.*
> another.jar = de/somecompany/somepackage
> yetanother.jar = org/apache/tools/ant/**/*
> yetanother.jar.exclude = org/apache/tools/ant/taskdefs/optional/**/*
> myjars = my.jar,another.jar,yetanother.jar
> (yes, myjars contains property names, not values)
> My object works like so:
> <eijar basedir="${classes.out.dir}"
> jarvarlist="${myjars}"
> destdir="${build.jar.dir}"
> />
> The non-standard addition there is 'jarvarlist'. My object does the
> with that var:
> For each name in jarvarlist, we do getProject().getProperty(
propertyname ),

no need to use getProject, its a member variable of Task: project.  Just an

> and that property contains a list of includes (or null). We pass that
> to super.setIncludes(). We then look for a optional var named
> "varname.exclude", and pass that value to setExcludes(). Then we just run
> super.execute(). It works fine, except that the behaviour in PatternSet
> it.

You sure do enjoy making life more difficult on yourself, don't you?!   :)

You jump through all sorts of hoops - and there is certainly easier ways to
do what you're doing.  I don't have the time to think through your very
non-standard probably-never-to-be-added-to-Ant-core <jar> hack, but you've
got to work with PatternSet as it exists - those setters are functioning as
they should. Think about it from the XML introspection perspective and
you'll hopefully see what I mean.

> Again - i *know* this is not a standard Ant approach, but i've done it
> way because, quite frankly, i don't want people mucking around with the
> build.xml unless they need to, and providing this functionality via
> properties is an easy way for people do mess with it.

Surely there are ways to build multiple JAR files which don't require such
hacks.  Heck, try the <foreach> and do it that way.

> To be clear, i'm not pushing for a fix to make this possible, but i am
> that PatternSet.set{Includes,Excludes}() violates it's API docs by saying
> that it sets the value, when in fact it appends to it, and that should be
> fixed (even if the fix is an API doc update).

Then the docs are broken.  Think about:

    <patternset id="patternset" includes="....">
        <include name="..."/>

Which of those patterns should it use? The one from the attribute?  Or the
nested element?  Or both?  If both, how will they get appended together?  :)

> As a workaround i would recommend changing it to:
> public void setIncludes(String includes) {
> ...
>         if (includes != null && includes.length() > 0) {
> // same
>         }
> else {
> // reset the list to empty.
> }
> }

No way.  -1.  'nuff said.


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

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

View raw message