Ok, this is an example from a build file in mutant (somewhat elided)
<patternset id="deprecated"> <exclude name="org/apache/tools/ant/taskdefs/Copydir.java"/> <exclude name="org/apache/tools/ant/taskdefs/Copyfile.java"/> </patternset>
<patternset id="toohard"> <exclude name="org/apache/tools/ant/taskdefs/AntStructure.java"/> <exclude name="org/apache/tools/ant/taskdefs/Recorder.java"/> <exclude name="org/apache/tools/ant/taskdefs/RecorderEntry.java"/> </patternset>
<patternset id="converted"> <exclude name="org/apache/tools/ant/taskdefs/Ant.java"/> <exclude name="org/apache/tools/ant/taskdefs/CallTarget.java"/> </patternset>
<fileset id="ant1src" dir="../../src/main"> <include name="org/apache/tools/ant/taskdefs/**/*.java"/> <patternset refid="deprecated"/> <patternset refid="toohard"/> <patternset refid="converted"/> </fileset>
This is exactly what I was talking about: using the current behaviour to get around the restrictions on refids. If they weren't there, you could also do this with:
<fileset id="ant1src" dir="../../src/main">
<patternset refid="deprecated">
<include name="org/apache/tools/ant/taskdefs/**/*.java"/>
</patternset>
<patternset refid="toohard"/>
<include name="org/apache/tools/ant/taskdefs/**/*.java"/>
</patternset>
<patternset refid="converted"/>
<include name="org/apache/tools/ant/taskdefs/**/*.java"/>
</patternset>
</fileset>Even with those restrictions, you could also put the includes in the original patternsets:
<patternset id="deprecated">
<include name="org/apache/tools/ant/taskdefs/**/*.java"/>
<exclude name="org/apache/tools/ant/taskdefs/Copydir.java"/>
<exclude name="org/apache/tools/ant/taskdefs/Copyfile.java"/>
</patternset> ... etcAll of that is redundant, though. What I think you are really saying is that you WANT to be able to fold patterns together. Fair enough. I still think the existing behaviour is wrong, though. It is overloading what a fileset is. A fileset is not a task for folding patterns together, it is a task for applying a patternset to a specific directory tree.
You could introduce some kind of pattern container, but why bother? It too would define a patternset. Why not something more like this:
<patternset id="deprecated">
<exclude name="org/apache/tools/ant/taskdefs/Copydir.java"/>
<exclude name="org/apache/tools/ant/taskdefs/Copyfile.java"/>
</patternset> <patternset id="toohard">
<exclude name="org/apache/tools/ant/taskdefs/AntStructure.java"/>
<exclude name="org/apache/tools/ant/taskdefs/Recorder.java"/>
<exclude name="org/apache/tools/ant/taskdefs/RecorderEntry.java"/>
</patternset> <patternset id="converted">
<exclude name="org/apache/tools/ant/taskdefs/Ant.java"/>
<exclude name="org/apache/tools/ant/taskdefs/CallTarget.java"/>
</patternset> <patternset id="taskdefs">
<include name="org/apache/tools/ant/taskdefs/**/*.java"/>
<patternset refid="deprecated"/>
<patternset refid="toohard"/>
<patternset refid="converted"/>
</patternset> <fileset id="ant1src" dir="../../src/main">
<patternset refid="taskdefs"/>
</fileset>This is much cleaner and clearer as a solution, in my opinion. It also gives you far more flexibility in how you combine different patterns together.
I'd guess the suggested change would break this. I guess my intutition is just different. I treat a patternset as a set of file selection patterns, not as a the file selections themselves. That is what I use filesets for.
I don't think this is fair comment. The issue is not whether patternsets stand for patterns or files. No one is suggesting putting a directory scanner into PatternSet. We're talking about whether to allow patterns to remain separate within a fileset rather than forcing them to be mingled together. The issue only arises when the patternset is within a fileset, though, so maybe that was the confusion.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
