regression against ant 1.6.5: a patternset cannot be redefined through itself. the problem may be illustrated using the following sample: ---------------------------------- <?xml version="1.0" encoding="iso-8859-1"?> <project name="Show Bug" default="all" basedir="."> <target name="all"> <patternset id="x.id"> <include name="*.a"/> </patternset> <patternset id="x.id"> <patternset refid="x.id"/> <include name="*.b"/> </patternset> <mkdir dir="target"/> <mkdir dir="src"/> <copy todir="target"> <fileset dir="src"> <patternset refid="x.id"/> </fileset> </copy> </target> </project> ---------------------------------- execute this sample with "-debug" key with ant 1.6.5 and 1.7.0: the log line where the patternset is shown is: ---- Setup scanner in dir /tmp with patternSet{ includes: [*.b, *.a] excludes: [] } ---- for ant 1.6.5, and ---- Setup scanner in dir /tmp with patternSet{ includes: [*.b] excludes: [] } ---- We can see that in 1.7.0 the previous content of the referred patternset is lost. This is the problem.
that is simply the way Ant references work. You could use a scriptdef to programmatically retrieve the original reference, then assign a new object which refers to the original object back to the same reference name. Another option would be to use the Ant 1.8 properties API to add a PropertySetter capable of setting a reference (so you use a different mechanism to set and get the reference). I will add this to the list of things to do for the props antlib as well.
(In reply to comment #1) > that is simply the way Ant references work. You could use a scriptdef to > programmatically retrieve the original reference, then assign a new object > which refers to the original object back to the same reference name. Another > option would be to use the Ant 1.8 properties API to add a PropertySetter > capable of setting a reference (so you use a different mechanism to set and get > the reference). I will add this to the list of things to do for the props > antlib as well. > Hi, Matt, sure, this may be easily worked around using another reference, for example. But the point of this bug request is just *compatibility* with 1.6.5 release. Do you know, why that worked in 1.6.5 in a different way than in 1.7.0?
Ah... you should then have marked that as a regression. That would require a little more research as I wouldn't have expected this ever to have worked.