Order of attributes signifificant in zipfileset?
Dave Glasser <dglasser <at> pobox.com>
2016-05-01 04:06:56 GMT
I discovered this in ant 1.6.5, and found that it still behaves this way in 1.9.7.
If you have a <zipfileset> element with both a dir and a file attribute, it will produce different results
depending on the order in which those attributes appear. If the file attribute appears first, it behaves
as you would expect. For example, with this:
<zipfileset file="file1.txt" dir="dir1"/>
It looks for a file named "file1.txt" inside the directory "dir1". However, with this:
<zipfileset dir="dir1" file="file1.txt"/>
It looks for file1.txt inside the current working directory. This can be verified by running the
demonstration target I provide below with the -debug switch, and reading the debug output.
I want to make clear that I'm aware that the docs for fileset say:
"Either dir or file must be specified" and that I might be doing it wrong. You could argue otherwise, but
perhaps that does in fact unambiguously imply that having both is incorrect and hence the behavior is
undefined. Be that as it may, what I would like to know is this:
Is this a known, and expected behavior? Is it documented anywhere?
Should I assume that the order of attributes is significant in other places throughout my build.xml file?
Here's a self-contained target that demonstrates this behavior:
<property name="JARCMD" value="jar"/>
<!-- Delete both zip files if they exist. -->
<property name="ZIP1" value="zip1.zip"/>
<property name="ZIP2" value="zip2.zip"/>
<property name="DIR1" value="dir1"/>
<!-- make sure there are no files named file1.txt or file2.txt in the
current directory, so we know they're not being read from there. -->