On 2009-01-28, Jesse Glick <jesse.gl...@sun.com> 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-) https://issues.apache.org/bugzilla/show_bug.cgi?id=20366 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="second.zip"/> <zipfileset src="some-other.zip"/> </zip> 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 > Zip.java better than I do. Did I sound like "if you think you understand Zip.java better than I do"? If so, please forgive me, this was in no way intended. > Note that in my test case, creating and deleting y.properties 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 testcase. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
