Bug 17780 - Instead of updating a jar file, the task overrides it
Instead of updating a jar file, the task overrides it
Product: Ant
Classification: Unclassified
Component: Core tasks
PC All
: P1 major with 2 votes (vote)
: 1.5.3
Assigned To: Ant Notifications List
: 18207 (view as bug list)
Depends on:
  Show dependency tree
Reported: 2003-03-07 17:43 UTC by Feng Yang
Modified: 2005-03-20 17:06 UTC (History)
1 user (show)

patch text file plus new java source (6.37 KB, application/octet-stream)
2003-03-11 17:17 UTC, Antoine Levy-Lambert

Note You need to log in before you can comment on or make changes to this bug.
Description Feng Yang 2003-03-07 17:43:45 UTC
Below is the build file:

<?xml version="1.0"?>

<project name="Test updating jar files" basedir="." default="jar.test">

    <!-- This target jars up *.class files in current directory into test.jar -->
    <target name="jar.test">
        <jar destfile="test.jar" basedir="."
        <!-- Update JAR manifest to include dependency libraries -->
        <jar destfile="test.jar" update="true">
               <attribute name="Class-Path" value="Some jar files"/>


I tested this build file with both 1.5.1 and 1.5.2.  1.5.1 worked perfect, the
test.jar contains the class files along with the manifest file.  However, when
built with 1.5.2, the test.jar contains only the manifest file.  It seems the
second task overrides the file even though the attribute "update" is set to true.
Comment 1 Stefan Bodewig 2003-03-10 08:02:09 UTC
How do you verify that the jar does not contain the class files?

If you used WinZIP, please try "jar tf test.jar" instead.  If things work, you can
mark this bug as duplicate of bug 17648.
Comment 2 Ben Jenkins 2003-03-10 20:26:41 UTC
I'm seeing this problem as well.

My application cannot access the missing files, so I do not think its a WinZip 
Comment 3 Feng Yang 2003-03-10 20:55:12 UTC
I used "tar tf test.jar" to check the existence of the files.  It was nothing to
do with zip.

The tests were run on Red Hat Linux 7.3 on i386 using Sun's JDK 1.3.1_05.
Comment 4 Antoine Levy-Lambert 2003-03-10 21:16:04 UTC
I believe these lines should be removed from Zip.java#executeMain

            // quick exit if the target is up to date

            // can also handle empty archives

            if (isEmpty(addThem)) {



This quick exit prevents the old zip entries from being copied from the old 
archive to the new when one is in update mode and that there is no file to add.
Comment 5 Ben Jenkins 2003-03-10 21:55:14 UTC
Nope, that doesn't fix it.

I added some debug to my local src copy of 1.5.2 and I see zipFile(InputStream) 
being called for all of the files that were in the original jar (see below).  
It looks like the original files *should* be getting jar'd up, but I can't 
figure out where the problem is.

      [jar] found original file META-INF/MYALIAS.DSA
      [jar] found original file META-INF/MYALIAS.SF
      [jar] found original file license.txt
      [jar] found original file version_info
      [jar] Adding original files
      [jar] Entering addResources()
      [jar] prefix=""
      [jar] dealingWithFiles=false
      [jar] name=META-INF/MYALIAS.DSA
      [jar] Entering addParentDirs()
      [jar] Leaving addParentDirs()
      [jar] ze=META-INF/MYALIAS.DSA
      [jar] Entering zipFile(java.util.zip.ZipFile$1@76e8a7, 
org.apache.tools.zip.ZipOutputStream@1aed5f9, META-INF/MYALIAS.DSA, 
1047331542000, C:\dynamicsoft\re\lib\dynamicsoft\zip803692068.tmp, 16877)
      [jar] adding entry META-INF/MYALIAS.DSA
      [jar] Leaving zipFile()
      [jar] name=META-INF/MYALIAS.SF
      [jar] Entering addParentDirs()
      [jar] Leaving addParentDirs()
      [jar] ze=META-INF/MYALIAS.SF
      [jar] Entering zipFile(java.util.zip.ZipFile$1@a45536, 
org.apache.tools.zip.ZipOutputStream@1aed5f9, META-INF/MYALIAS.SF, 
1047331542000, C:\dynamicsoft\re\lib\dynamicsoft\zip803692068.tmp, 16877)
      [jar] adding entry META-INF/MYALIAS.SF
      [jar] Leaving zipFile()
      [jar] name=license.txt
      [jar] Entering addParentDirs()
      [jar] Leaving addParentDirs()
      [jar] ze=license.txt
      [jar] Entering zipFile(java.util.zip.ZipFile$1@d66426, 
org.apache.tools.zip.ZipOutputStream@1aed5f9, license.txt, 1045261202000, 
C:\dynamicsoft\re\lib\dynamicsoft\zip803692068.tmp, 16877)
      [jar] adding entry license.txt
      [jar] Leaving zipFile()
      [jar] name=version_info
      [jar] Entering addParentDirs()
      [jar] Leaving addParentDirs()
      [jar] ze=version_info
      [jar] Entering zipFile(java.util.zip.ZipFile$1@1490eb5, 
org.apache.tools.zip.ZipOutputStream@1aed5f9, version_info, 1047331542000, 
C:\dynamicsoft\re\lib\dynamicsoft\zip803692068.tmp, 16877)
      [jar] adding entry version_info
      [jar] Leaving zipFile()
      [jar] Leaving addResources()
      [jar] Entering finalizeZipOutputStream()
      [jar] Leaving finalizeZipOutputStream()
      [jar] Leaving execute()
Comment 6 Antoine Levy-Lambert 2003-03-11 17:17:01 UTC
Created attachment 5269 [details]
patch text file plus new java source
Comment 7 Stefan Bodewig 2003-03-12 11:31:59 UTC
Ben, I'm quite sure that your case is a duplicate of bug 17648.

Anyway, both bugs are supposed to be fixed now.  Could you please replace ant.jar
from Ant 1.5.2 with this one <http://cvs.apache.org/~bodewig/ant.jar> and
verify that it fixes all problems you have encountered?
Comment 8 Ben Jenkins 2003-03-12 14:11:07 UTC

The new ant.jar you provided fixes all my problems.

Thank you for your quick response!
Comment 9 Stefan Bodewig 2003-03-21 07:11:35 UTC
*** Bug 18207 has been marked as a duplicate of this bug. ***
Comment 10 Stefan Bodewig 2003-04-01 14:48:45 UTC
What is the point of changing the severity of a "fixed" bug?