ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <>
Subject Re: The zip update problem
Date Thu, 09 Jan 2003 08:47:21 GMT
I have tried the hack solution 3) myself ; I have the impression that it is
dirty [lengthy functions with a lot of ifs ], and will be more difficult to
debug and support than a clean solution 2).
I would rather go for 2). The bug has been around since the 12th of July
last year when it has been reported by Sven Karlsen.
I don't know how important it is not to delay 1.5.2 . Maybe it is possible
to solve the bug 10755 both quickly and cleanly, if all the ant community
contributes to solving it.


----- Original Message -----
From: "Stefan Bodewig" <>
To: <>
Sent: Thursday, January 09, 2003 9:04 AM
Subject: The zip update problem

> The mail I promised yesterday but didn't manage to write since the
> Gump/xdoclet problem is eating too much time ...
> I'm talking about bug 10755 here.  The update feature of <zip> has
> never worked, but it is broken in different ways in our past releases.
> In Ant 1.4.x, update="true" would have recreated the archive all the
> time, in 1.5.x it will never get recreated unless the files that are
> to be added to the archive are newer than the archive (which means
> "never" if the archive gets created during the build in the first
> place).
> I've been thinking about solving this in a most general way by
> extending the underlying concepts in SourceFileScanner so that it can
> deal with targets or sources that are not Files, but ZipEntrys (or at
> a later point URLs or TarEntrys or ...).  I had some initial ideas [1]
> that I've not been too happy with and Magesh and Dominique have proven
> that more thought needs to be put into the API.  Later I ran out of
> time (and my kids wouldn't allow me to code during my vacation, right
> they were 8-).
> In the meantime, some people have suggested patches in bugzilla that
> would lead to a simpler but more specific solution (most notably
> Antoine Levy-Lambert).
> Putting things together, a good solution with an API that we'd want to
> support in the future doesn't fit into the timeframe for a 1.5.2
> release, if we are talking about end of January IMHO.
> I see three options here:
> (1) don't fix it in the 1.5 branch at all.
> (2) delay 1.5.2 until we are happy with a general fix.
> (3) fix it in the 1.5 branch using cut'n'paste and private methods and
> hacks and such (so that we don't add any public API that needs to be
> supported in the future) and get it right in 1.6.
> I'm leaning towards (3) but want to get some feedback before I proceed
> in that direction.  After that I'd like to start discussion on what
> "get it right" would be.
> Stefan
> Footnotes:
> [1]  <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message