On Thu, 09 Dec 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> When update is "false", the user wants the set the zip file to the
> contents of the zip command.
I agree with you, the current behavior is a bug. I even vaguely
recall a bugzilla report about it.
Stefan
---
Matt Benson <[EMAIL PROTECTED]> writes:
> Ohh... sorry I had misunderstood the issue. To test
> myself, could that be restated as "If all files from
> the fileset are up to date in the archive, no change
> is made, regardless of whether the archive also
> contains extraneous files that should be
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
[SNIP]
> The issue was with update="false", not with
> update="true".
>
> When update is "false", the user wants the set the
> zip file
> to the contents of the zip command. Files in the zip
> file that
> are not in the zip tasks fileset are removed from
Matt Benson wrote:
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
Ah, I see.
This does look like a bug.
Is it? Or is it just the way update="true" works and
therefore a documentation issue? From the manual:
The issue was with update="false", not with update="true".
When update is "false",
Matt Benson <[EMAIL PROTECTED]> writes:
> --- Peter Reilly <[EMAIL PROTECTED]> wrote:
>
>> Ah, I see.
>> This does look like a bug.
>
> Is it? Or is it just the way update="true" works and therefore a
> documentation issue? From the manual:
>
> The update parameter controls what happens if the Z
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
> Ah, I see.
> This does look like a bug.
Is it? Or is it just the way update="true" works and
therefore a documentation issue? From the manual:
The update parameter controls what happens if the ZIP
file already exists. When set to yes, the ZIP file
Ah, I see.
This does look like a bug.
I was about to say only the date of the zip file is used for
dependency checking, but this is not the case, so any
names that are not in the filesets could be used to trigger
a new zip file when update="false".
Peter
Yves Martin wrote:
In fact, my test does not
Peter Reilly <[EMAIL PROTECTED]> writes:
> I do not see the behaviour you describe:
>
>
>
>
>
>destfile="newfile.zip"
> whenempty="create"
> duplicate="fail"
> update="false">
>
>
>
> jar tf newfile.zip
>
>
I do not see the behaviour you describe:
jar tf newfile.zip
jar tf newfile.zip
jar tf newfile.zip
the output is:
test:
[delete] Deleting: /home/preilly/learning/a/zip/newfile.zip
[zip
Hello,
I find the behavior of 'zip' strange when writing my build.xml. So I extracted
a test case:
What is the problem ?
If newfile.zip already exists with 'file3' inside, 'file3' remains because
'zip' seems to work in 'append'
10 matches
Mail list logo
