ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Status update 10755
Date Wed, 05 Feb 2003 11:39:38 GMT
First the good news: It is supposed to be fixed now.  I've just
started a fresh Gump session and see whether anything gets broken, but
it is not too likely as Gump will probably create fresh archives for
almost everything, so it is no real test.

One thing that I still have to look into is the check whether the
manifest is up-to-date in Jar.  I've left the code more or less
unchanged, but I think it is just wrong.  The correct approach IMHO
would be to create the Manifest object in memory (the one we would
write) and compare it to the one found in the original (if any).  The
current code is a mixture of parts of this with some simple file
timestamp based checks that look suspicious.

I had to disable a test-case, <zip>'s test4.  test4 is this

  <target name="test4">
     <zip destFile="test4.zip"
         basedir="."/>
  </target>

and expects the task to fail with "archive cannot contain itself" even
if test4.zip doesn't exist.  The old code would start writing to
test4.zip and after that scan the directory, thus the failure.  The
new code scans the directories before it starts to write -> no error.

Does anybody feel the old behavior must be preserved?

And then there is one thing that is really ugly - the code in Jar.java
that is labeled with "OK, this is a hack".  This has been a first shot
and has to do with our "jars are never empty" policy.

I think it would be cleaner to write the manifest in createEmptyZip
and remove the hack completely.  I'll look into this sometime later
this week.

Stefan

Mime
View raw message