*** Bug 10823 has been marked as a duplicate of this bug. ***

I'm seeing basically this same problem with the <zip> task, which is the
superclass of the <jar> task.

I backed out the changes of rev. 1.78.2.6 from
org/apache/tools/ant/taskdefs/Zip.java and things started working again. 
According to the CVS logs, these changes were made to address bug 8069.

Yes.

In Ant 1.4.1 <zip>'s update didn't work - it would always update the zip file.

Now in 1.5 it doesn't work as expected, it will only update the zip file if the
files you want to add are newer than the archive.  This is consistent with
<zip> not recreating an archive if the archive is newer than the files you'd
like to see in it when update is false.

*** Bug 11039 has been marked as a duplicate of this bug. ***

Hi!

This is not exactly the same as described in Bug #11093, which has been marked 
as a DUPLICATE this one.

After evaluating the exact issue behind Bug #11093, I found out, that updating 
a WAR with a file, which already exists in the WAR, works fine on Windows NT/2K 
and SuSE-Linux 7.3 Intel, Kernel 2.4.x, but fails on SuSE-Linux 7.0 zSeries 
IBM, Kernel 2.2.16. I think this could be related to the different versions of 
JDKs. Windows and Intel-Linux are using Sun JDKs, but the zSeries needs an IBM 
JDK. This probably should become a new Bug.

I have a simalr situation when trying to add files to a jar using <jar> and 
<zip>. The first task adds files properly bu the second produces an error for 
each file to be added, stating that the target jar is "up to date" and the file 
to be added is "skipped".

Target looks like this:
    <target name="jar" depends="compile" description="Create client jar file">
        <jar destfile="${jar.file.name}.jar" includes="**" 
basedir="${dest.dir}" manifest="ant/dashclient-nosign.mf" update="true" />
        <zip destfile="${jar.file.name}.jar" update="true" >
            <zipfileset src="shared/Cnnxn/CnnxnUtils.jar" excludes="META-
INF/MANIFEST.MF" />
        </zip>
    </target>


I was able to workaround the problem by adding a <touch> task between the <jar> 
and <zip> tasks using a date that I know is in the past.

    <target name="jar" depends="compile" description="Create client jar file">
        <jar destfile="${jar.file.name}.jar" includes="**" 
basedir="${dest.dir}" manifest="ant/dashclient-nosign.mf" update="true" />
        <touch file="${jar.file.name}.jar" datetime="06/28/2000 2:02 pm"/>
        <zip destfile="${jar.file.name}.jar" update="true" >
            <zipfileset src="shared/Cnnxn/CnnxnUtils.jar" excludes="META-
INF/MANIFEST.MF" />
        </zip>
    </target>

Peter Hale phale@cnnxn.com

*** Bug 11209 has been marked as a duplicate of this bug. ***

*** Bug 11623 has been marked as a duplicate of this bug. ***

We have a similar problem using the zip task.
We have some files that should be compressed in the
zip archive and some that are just stored. (.gifs)

When ant stores the files it reports the archive as
up to date and nothing was stored.

If I use the touch workaround, it stores the the files
allright BUT it uncompress all existing files and
stores them uncompressed.

(Btw, touch millis="10" does not work as a workaround.)

*** Bug 11699 has been marked as a duplicate of this bug. ***

*** Bug 11756 has been marked as a duplicate of this bug. ***

*** Bug 12028 has been marked as a duplicate of this bug. ***

*** Bug 13783 has been marked as a duplicate of this bug. ***

Created attachment 3574 [details]
Suggestion on how to fix this bug.

To address the issue that a .zip or .jar cannot be updated depending on an
existing or outdated entry in the archive, I've started digging into the Mergers
and Scanners that decide about this magic, and have added a few lines to
SourceFileScanner.java that make it actually look into the archive, which as far
as I can see noone did before. Since the documentation says that "New files are
added; old files are replaced with the new versions.", I believe that this is
the correct (and most useful) behaviour. The code may not be the most beautiful
piece in the world, but it solves the problem perfectly, at least for zips and
jars. I have not tested it for tars. I hope that the attached cvs diff can be
used to fix this issue generally.

-- best regards,
Peter Holzwarth
mailto:peter.holzwarth@io-software.com

*** Bug 14044 has been marked as a duplicate of this bug. ***

*** Bug 14563 has been marked as a duplicate of this bug. ***

*** Bug 14586 has been marked as a duplicate of this bug. ***

Peter, thank you for the patch - unfortunately it won't work that easy.

Apart from the fact that there are more tasks that use MergeMappers, your patch
wouldn't take things like the prefix and fullpath attributes of <zipfileset> into
account.

I agree that SourceFileScanner is the way to go and I'm going to look into it
in the next few days, but I'm going to approach it from a different angle.  I'll
probably add a new attribute to zip that needs to be set to actually look into
the archive - one could argue that looking into the archive should be the default
for update="true".

*** Bug 15304 has been marked as a duplicate of this bug. ***

Created attachment 4334 [details]
patch for the task Zip

Created attachment 4335 [details]
patch for the ZipScanner file

Created attachment 4336 [details]
Patch for the Jar task

I have done a smoke test concerning these 3 patches.
When one does what Sven Karlsen describes 
(build first an empty jar, then add one file for instance build.xml), the jar tasks notices that 
build.xml is missing the second time and rebuilds it.
I have also done a smoke test with a zipfile 
task containing zipfilesets, similar to what is in the ant manual, including a zipfileset coming 
from a zip file.
Here is what I have played with :
<?xml version="1.0"?>
<project 
name="Expose a Bug in Ant's Jar Task" default="jar" basedir=".">
<!-- <touch file="build.xml" 
datetime="06/28/2000 2:02 pm"/> -->
  <target name="jar">
    <jar jarfile="test.jar"
      
basedir="."
      excludes="*"/>

    <jar jarfile="test.jar"
      basedir="."
      
includes="build.xml"
      excludes="test.jar"/>

  </target>
  <target name="jar2">
    
<jar jarfile="test.jar"
      basedir="."
      includes="build.xml"
      
excludes="test.jar"/>

    <jar jarfile="test.jar"
      basedir="."
      
includes="build.xml"
      excludes="test.jar"/>

  </target>
  <target name="zip">
    
<touch file="htdocs/manual/inputhandler.html" datetime="06/28/2000 2:02 pm"/>
      <zip 
destfile="manual.zip">
         <zipfileset dir="htdocs/manual" prefix="docs/user-guide"/>
         
<zipfileset dir="." includes="ChangeLog27.txt" fullpath="docs/ChangeLog.txt"/>
        
<zipfileset src="examples.zip" includes="**/*.html" prefix="docs/examples"/>
    
</zip>
    <!-- <echo message="Hello, world" file="htdocs/manual/text.html"/> -->
      <zip 
destfile="manual.zip">
         <zipfileset dir="htdocs/manual" prefix="docs/user-guide"/>
         
<zipfileset dir="." includes="ChangeLog27.txt" fullpath="docs/ChangeLog.txt"/>
        
<zipfileset src="examples.zip" includes="**/*.html" prefix="docs/examples"/>
    
</zip>
    <delete file="htdocs/manual/text.html" quiet="true"/>
  </target>
</project>

*** Bug 15906 has been marked as a duplicate of this bug. ***

A quick update to let you know that this bug has not been forgotten:

http://marc.theaimsgroup.com/?l=ant-dev&m=104209947417287&w=2

working on it ...

For me the problem is, that I want to use the "update" option to add more files to the jar, but because 
these files are older than the freshly created jar, they won't be added. This assumptation is 
wrong. These test should only happen, if the files to add are already in the jar; if they aren't, 
they must be added - no matter, what file-time they have.

Alternative: provide another option 
to *add* files.

For some preliminary feedback, could some of you please try the nightly build of
<http://cvs.apache.org/builds/jakarta-ant/nightly/> 2003-01-22 or later?

The <jar> task is now supposed to update the archives correctly.

Should this now also do an update if a file in the archive is older than a 
source file, but the archive is newer? A first test didn't work, so I'd like to 
ask before we spend more time.

Yes, it should add files that are older than the archive as well as update
the archive if the files inside are older than the files to add/update.

If it doesn't work, I have some more work to do 8-(

A build-file snippet might help.  As I said, I wanted some preliminary feedback,
don't spend too much time with it.

Thanks.

To my opinion, in the current CVS head version, the date time of the archive itself is irrelevant. 
What is being compared are the date/time of the archive entries versus the date/time of the files 
to be archived.

I have a long classpath (990 characters).  I wanted to test the fix, but I 
haven't been able to.

When ant_home points to my 1.5.1 ant directory, and I run "ant -version", I get

Apache Ant version 1.5.1 compiled on October 2 2002

If I change ant_home to point to 1.6alpha, I get

The input line is too long.
:gotAllArgs
 was unexpected at this time.

Changing the path so that the 1.6alpha ant.bat is run doesn't change the result.

 

 

For a test, you could remove all the ant-*.jar files from the lib directory as
optional.jar should contain all of their contents anyway.

Created attachment 4530 [details]
Test setup

Created attachment 4537 [details]
Ok, found the interesting test case now... See next comment.

Testing of files in folders seems not to happen. Could be caused by a missing 
.replace('\\', '/') for Windows folders ? I haven't looked into the source so 
far, so this is just a suggestion. See the tests in Attachment id=4537. They 
show that the behaviour is not what we would expect.

I had already found some problems with directory entries themselves - and fixed
them.

Thank you for the test cases, I'll look into them.

Peter, what are the result you are getting?  Can you give me the -debug output
from using the 1.6alpha code?

I'm not using Windows myself and it seems to work for me.  This could be a platform
issue or mean that my latest patches have fixed it.

Created attachment 4538 [details]
The attached zip contains the log output from my WinXP installation.

Peter, we have a combination of problems here.

First, there has been a platform issue, that should be fixed now.  Could you 
please retry with the next nightly build (-01-28) or use this one
<http://cvs.apache.org/~bodewig/ant.jar>?

The second problem is your test with a file that is only half a second newer than
the one stored last time around, this is not going to work by any means.

ZIP archives store time with a granularity of two seconds.  If we want to avoid
an "always updates" problem, we need to round up to the next higher even number
of seconds when storing the entries - this may lead to situations where <zip> and
friends will not update an archive for a newer file, if that file is less than
two seconds newer than the originally stored one.  I don't see a solution here.

The 01-28 build works fine for me.

If I could vote for a behaviour in situations where the file to be updated and 
the file in the archive are in the same 2 seconds interval, I would prefer 
doing the update always in this case since this seems to be the best guess one 
can make.

Were we to always add a file if its date stamp were within two seconds, we would always 
be adding files even if they duplicated what is in the archive, which is often not what is 
desired.

We can get this behavior, I believe, from the update attribute.  If it is set to "false', will it not 
always add the file?

(If I am wrong, then I can see the need for a "force" attribute that always replaces.)

Finally - fixed.

Please use the latest build from http://cvs.apache.org/~bodewig/gump/ant1.5.2alpha/
to confirm that zip and friends now work as expected.  What you find there is
quite close to what will be Ant 1.5.2beta1, but doesn't include all optional tasks.

The tasks in 1.5.2alpha work great for us! Thanks!

-- Peter Holzwarth.

*** Bug 17684 has been marked as a duplicate of this bug. ***

I was using the nightly build from Jan 28th until just recently, and that 
version worked as I expected the <jar update="true"> task to work:  It added 
files regardless of date and never removed files already existing in the jar.

I've just tried it with the 1.5.2 build, and in all my projects save one, it 
works fine.  But in one case I am finding that it is removing some pre-existing 
files (my ejb-jar.xml, which is how I noticed)

If necessary I can provide more test information.

Well, I introduced a new most-popular bug in 1.5.2's <zip> 8-(

How do you add your ejb-jar.xml?  I bet it uses <zipfileset>s internally in some
way.  My guess is that the file is not really missing, you just don't see it
in WinZIP (could you try "jar tf filename" instead?)

If I'm correct, your report is a duplicate of bug 17648 and - thank god - no
regression of this one here.

You are correct.  I'll set this back to fixed and verify 17648 next week.  
Thanks.

*** Bug 21082 has been marked as a duplicate of this bug. ***

*** Bug 13783 has been marked as a duplicate of this bug. ***

Created attachment 19869 [details]
ned