ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: web site example does not work
Date Tue, 29 Jun 2010 14:21:20 GMT
On 2010-06-29, SZEDER Gábor wrote:

> On Tue, Jun 29, 2010 at 01:51:59PM +0200, Stefan Bodewig wrote:
>> On 2010-06-29, Stefan Bodewig wrote:

>>>>>>    <zipfileset includes="**/*.class">
>>>>>>      <fileset dir="lib/main" includes="**/*.jar"/>
>>>>>>    </zipfileset>

>>> It looks as if the example wanted to use zipgroupfileset instead of
>>> zipfileset.

>> No, that wouldn't work either.  <zipgroupfileset> cannot filter its
>> contents.

>> <restrict>
>>   <name name="**/*.class"/>
>>   <archives>
>>     <zips>
>>       <fileset dir="lib/main" includes="**/*.jar"/>
>>     </zips>
>>   </archives>
>> </restrict>

>> is a correct way to do what the example promises,

> Yes, this works here, too.

So I provided at least one correct answer ;-)

>> as would be

>> <restrict>
>>   <name name="**/*.class"/>
>>   <zipgroupfileset dir="lib/main" includes="**/*.jar"/>
>> </restrict>

> But this does not work, because "restrict doesn't support the nested
> "zipgroupfileset" element."

This is because zipgroupfileset is not a standalone resource collection
but only supported as nested element of the zip task.  I forgot about
that, but this is the reason we added the more generic archives resource
collection in 1.8.0.

> Interesting sidenote:
> Your first variant takes "Total time: 19 seconds", while the following
> snipplet only takes "Total time: 3 seconds" on the same set of files
> to produce a jar file with the same contents.

> <unjar dest="${unjardir}" overwrite="false">
>         <fileset dir="${lib}" includes="**/*.jar"/>
> </unjar>
> <jar jarfile="${testjar}">
>         <fileset dir="${unjardir}" includes="**/*.class"/>
> </jar>

Whenever we deal with reading from zips in a resource collection - be it
for <zipfileset> or <archives> - we open the archive, parse the central
directory, position at the entry we want to extract, hand out the
resource and close the archive.  Yes, this is horrribly inefficient but
so far we don't have any other good solution that ensures that we'll
close the archive we read from properly.

<tarfileset> or the <tar> child of <archives> doesn't exhibit the same
problem (neither do the cpio and ar variants in the unreleased compress
Antlib) because the tar format can properly be read from in a streaming


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

View raw message