You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dave Glasser <dg...@pobox.com> on 2016/04/26 20:18:57 UTC
Order of attributes significant in zipfileset?
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:
<target name="oa">
<property name="JARCMD" value="jar"/>
<!-- Delete both zip files if they exist. -->
<property name="ZIP1" value="zip1.zip"/>
<property name="ZIP2" value="zip2.zip"/>
<delete file="${ZIP1}"/>
<delete file="${ZIP2}"/>
<property name="DIR1" value="dir1"/>
<mkdir dir="${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. -->
<fail
message="A file named file1.txt exists in the current directory.">
<condition><available file="file1.txt"/></condition>
</fail>
<fail
message="A file named file2.txt exists in the current directory.">
<condition><available file="file2.txt"/></condition>
</fail>
<touch file="${DIR1}/file1.txt"/>
<touch file="${DIR1}/file2.txt"/>
<zip destfile="${ZIP1}">
<zipfileset file="file1.txt" dir="${DIR1}"/>
<zipfileset file="file2.txt" dir="${DIR1}"/>
</zip>
<zip destfile="${ZIP2}">
<zipfileset file="file1.txt" dir="${DIR1}"/>
<!-- This file will not be included, because the dir attribute
comes before the file attribute. -->
<zipfileset dir="${DIR1}" file="file2.txt"/>
</zip>
<echo>Contents of ${ZIP1}:</echo>
<exec dir="." executable="${JARCMD}">
<arg value="-tvf"/>
<arg value="${ZIP1}"/>
</exec>
<echo>Contents of ${ZIP2}:</echo>
<exec dir="." executable="${JARCMD}">
<arg value="-tvf"/>
<arg value="${ZIP2}"/>
</exec>
</target>
Re: Order of attributes significant in zipfileset?
Posted by Dave Glasser <dg...@pobox.com>.
From: "Caldarale, Charles R" <Ch...@unisys.com>
To: Tomcat Users List <us...@tomcat.apache.org>; Dave Glasser <dg...@pobox.com>
Sent: Tuesday, April 26, 2016 2:32 PM
Subject: RE: Order of attributes significant in zipfileset?
>> From: Dave Glasser [mailto:dglasser@pobox.com]
>> Subject: Order of attributes significant in zipfileset?
>
>> 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.
>
>Not surprising.
Really? Not surprising at all? I've never encountered a piece of software where the order of attributes on an input XML document mattered. AFAICT, you can't enforce the order of attribute names through a DTD or schema. Even W3C says "Notethat the order of attribute specifications in a start-tag or empty-elementtag is not significant." So, to me, it's quite surprising to encounter a situation where the order of attributes makes such a dramatic (but non-obvious) difference.
>> 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.
>
>
>Yes, it's undefined. The file attribute is documented as a "shortcut for specifying a single-file fileset" - you should not use both dir and file. If you want a single file in a particular directory, use just the file attribute:
>
><zipfileset file="dir1/file1.txt"/>
Yep, that's pretty much what I figured. Or just use the includes attribute instead of file. That seems to work the way you'd expect it to, and the documentation is clear and unambiguous. I was just hoping maybe someone had some deeper information on this beyond an interpretation of the documents.
RE: Order of attributes significant in zipfileset?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Dave Glasser [mailto:dglasser@pobox.com]
> Subject: Order of attributes significant in zipfileset?
> 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.
Not surprising.
> 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.
Yes, it's undefined. The file attribute is documented as a "shortcut for specifying a single-file fileset" - you should not use both dir and file. If you want a single file in a particular directory, use just the file attribute:
<zipfileset file="dir1/file1.txt"/>
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Order of attributes significant in zipfileset?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dave,
Off-topic, but okay.
On 4/26/16 2:18 PM, Dave Glasser wrote:
> 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?
I think anything not documented should be considered "undefined".
I tend to agree with you, however, that the order of the attributes
effect the behavior is a little surprising.
> 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:
> <target name="oa">
> <property name="JARCMD" value="jar"/>
>
> <!-- Delete both zip files if they exist. -->
> <property name="ZIP1" value="zip1.zip"/>
> <property name="ZIP2" value="zip2.zip"/>
> <delete file="${ZIP1}"/>
> <delete file="${ZIP2}"/>
>
> <property name="DIR1" value="dir1"/>
> <mkdir dir="${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. -->
> <fail
> message="A file named file1.txt exists in the current directory.">
> <condition><available file="file1.txt"/></condition>
> </fail>
>
> <fail
> message="A file named file2.txt exists in the current directory.">
> <condition><available file="file2.txt"/></condition>
> </fail>
>
> <touch file="${DIR1}/file1.txt"/>
> <touch file="${DIR1}/file2.txt"/>
>
> <zip destfile="${ZIP1}">
> <zipfileset file="file1.txt" dir="${DIR1}"/>
> <zipfileset file="file2.txt" dir="${DIR1}"/>
> </zip>
>
> <zip destfile="${ZIP2}">
> <zipfileset file="file1.txt" dir="${DIR1}"/>
>
> <!-- This file will not be included, because the dir attribute
> comes before the file attribute. -->
> <zipfileset dir="${DIR1}" file="file2.txt"/>
> </zip>
>
> <echo>Contents of ${ZIP1}:</echo>
> <exec dir="." executable="${JARCMD}">
> <arg value="-tvf"/>
> <arg value="${ZIP1}"/>
> </exec>
>
> <echo>Contents of ${ZIP2}:</echo>
> <exec dir="." executable="${JARCMD}">
> <arg value="-tvf"/>
> <arg value="${ZIP2}"/>
> </exec>
> </target>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: OT: Re: Order of attributes significant in zipfileset?
Posted by Dave Glasser <dg...@pobox.com>.
Good to know! Thanks George!
From: George Sexton <ge...@mhsoftware.com>
To: Tomcat Users List <us...@tomcat.apache.org>
Sent: Tuesday, April 26, 2016 4:06 PM
Subject: OT: Re: Order of attributes significant in zipfileset?
This isn't as bad as the delete task.
If you specify dir and file, it will delete everything in dir, not just
file.
OT: Re: Order of attributes significant in zipfileset?
Posted by George Sexton <ge...@mhsoftware.com>.
This isn't as bad as the delete task.
If you specify dir and file, it will delete everything in dir, not just
file.
On 4/26/2016 12:18 PM, Dave Glasser wrote:
> 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:
> <target name="oa">
> <property name="JARCMD" value="jar"/>
>
> <!-- Delete both zip files if they exist. -->
> <property name="ZIP1" value="zip1.zip"/>
> <property name="ZIP2" value="zip2.zip"/>
> <delete file="${ZIP1}"/>
> <delete file="${ZIP2}"/>
>
> <property name="DIR1" value="dir1"/>
> <mkdir dir="${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. -->
> <fail
> message="A file named file1.txt exists in the current directory.">
> <condition><available file="file1.txt"/></condition>
> </fail>
>
> <fail
> message="A file named file2.txt exists in the current directory.">
> <condition><available file="file2.txt"/></condition>
> </fail>
>
> <touch file="${DIR1}/file1.txt"/>
> <touch file="${DIR1}/file2.txt"/>
>
> <zip destfile="${ZIP1}">
> <zipfileset file="file1.txt" dir="${DIR1}"/>
> <zipfileset file="file2.txt" dir="${DIR1}"/>
> </zip>
>
> <zip destfile="${ZIP2}">
> <zipfileset file="file1.txt" dir="${DIR1}"/>
>
> <!-- This file will not be included, because the dir attribute
> comes before the file attribute. -->
> <zipfileset dir="${DIR1}" file="file2.txt"/>
> </zip>
>
> <echo>Contents of ${ZIP1}:</echo>
> <exec dir="." executable="${JARCMD}">
> <arg value="-tvf"/>
> <arg value="${ZIP1}"/>
> </exec>
>
> <echo>Contents of ${ZIP2}:</echo>
> <exec dir="." executable="${JARCMD}">
> <arg value="-tvf"/>
> <arg value="${ZIP2}"/>
> </exec>
> </target>
>
>
--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com