ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Bugzilla Issue 45902 (Up-to-date checks for JARs broken due to comparison of dir timestamps)
Date Thu, 29 Jan 2009 11:15:20 GMT
On 2009-01-28, Jesse Glick <> wrote:

> Stefan Bodewig wrote:
>> <zip> has been changed to ignore directory resources

> The intent was to ignore timestamp changes in directory resources
> when determining whether or not to rebuild an existing JAR, not to
> ignore directories altogether.

>> * a single empty directory is added to the sources - I think Ant will
>>   now no longer create a new archive

> Is this really a bug?

Some people say so 8-)

In any case it is a use case we currently support.

>> * we are updating a zip or reading from another ArchiveFileSet and the
>>   directories have Unix permissions set that are different from the
>>   tasks-level permissions - I'm afraid we are going to lose the
>>   original permissions.

> Only during an incremental build after changing the source
> permissions, right?

I'm not sure.  When doing something like

<zip ...>
  <zipfileset src=""/>
  <zipfileset src=""/>

we try to preserve the original permissions IIRC.  It's been quite
some time since I looked at the code.

>> there may be more problems with this approach.

> There may. Feel free to revert/fix if you think you understand
> better than I do.

Did I sound like "if you think you understand better than I
do"?  If so, please forgive me, this was in no way intended.

> Note that in my test case, creating and deleting changes
> the timestamp of the dir. It would be OK if Zip therefore recreated
> the archive _once_ (the "second" run). But it keeps on recreating it
> over and over, apparently because the timestamp of the dir entry does
> not get updated.

I agree.  We may have two issues here.  One is that in many if not
most cases you don't really care for the timestamps of the directories
so even the second task shouldn't recreate the archive.  And if you
do, the third and fourth tasks shouldn't do anything.

I'd suggest to throw in a new attribute to state whether you are
interested in directory timestamps - and would even go so far to make
it default to false.

Saying the archive is out of date because of the timestamp and then
not changing the timestamp on the second run is certainly a bug.

I'll try to add a few more testcases and see whether I can work
something out.  I don't see any reason to revert the patch or pull the


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

View raw message