ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Tar and resource collections
Date Wed, 19 Oct 2005 19:16:55 GMT
Hi all,

I think this one has earned an extra mail since it has some subtle
effects beyond "hey, I can tar up a path now".

<tar> supports resources now, any resources.

All protected method signatures in <tar> remained unchanged, I just
added a few new ones.  Classes extending <tar> shouldn't notice,
they'll reject non-file resources, but any file-system resource
collection should magically be supported by them as well.  Not that I
was aware of any subclass.

<tarfileset> is a stand-alone data-type now and can read from a source
archive (just like <zipfileset> did).

<zipresource> and <tarresource> know their Unix permissions (read from
the archive) and in <tarresource>'s case their Unix owner and group
information as well.

If you add <zipresource>s (like from a <zipfileset src="...">) or
<tarresources> (ditto) to a <tar>, the original permissions and owners
get retained (unless overridden by the attributes on *fileset).

This lead me to the commented out changes in Ant's build.xml:

    <tar longfile="gnu"
      <zipfileset src="${dist.base.binaries}/${}"/>

would allow us to read the permissions from the zip file instead of
duplicating the patterns.

Just, it is slow, really really slow.  Replacing both tar tasks made
"ant distribution" go from 2:45 to 6:39 on my 2GHz Pentium M WinXP
(yes, my work machine) notebook.

The reason for this is that with the <zipfileset> approach, the zip
archive gets opened and read once for scanning and then once per
resource that is added to the tar archive.  I don't see any easy way
around that, though.


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

View raw message