ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <>
Subject Re: Incrementally updating jar file - <touch> workaround does not work
Date Mon, 14 Apr 2003 19:23:12 GMT
Dear Jay,
Your problems are solved with ant 1.5.3
touch is not needed any more if you are building a jar file step by step.
----- Original Message -----
From: "Jay Goldman" <>
To: "Ant Users List" <>
Sent: Monday, April 14, 2003 9:15 PM
Subject: Incrementally updating jar file - <touch> workaround does not work

> I know there have been earlier discussions regarding how the <jar> task
> update="true" does not update the jar if the fileset contains files older
> than the timestamp on the jar file itself regardless of whether any of the
> individual files are actually newer than the corresponding ones inside the
> jar file.
> For historical reasons, my build scripts incrementally add files to a jar
> file and moreover the 'add' step occurs after all of the files have been
> created during a  'build' phase - so it is guaranteed that some of the
> to be added will be 'older' than the jar file as it is being incrementally
> added to.
> The workaround i have been using is to <touch> the jar file with
> to force the update to the jar file. This had been working ok until i
> using 1.5.3. I now get an error when my 'update jar task' is invoked when
> the jar file does not already exist. This appears to be due to the fact
> the <touch> task creates an empty file (such a file would obviously not
> contain any manifest, i.e., an empty file is not really a valid jar file,
> guess). This was not a problem before. Has anyone else seen this? Was the
> <jar> task implementation changed in this regard?
> I realize i can work around this new behavior by conditionally invoking
> <touch> based on the <available>ity of the jar file - but we all know the
> issues about writing logic using ant tasks, properties, 'if' attributes
> It just clutters up the build file.
> So i was wondering if this new behavior is the desired one or this was the
> unintended consequence of some other change or there is a better
> (besides changing the way the build process is structured.)
> thanks,
> Jay Goldman
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message