Return-Path: 
 <ant-dev-return-13658-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 34966 invoked by uid 500); 10 May 2001 11:57:24 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 34952 invoked from network); 10 May 2001 11:57:23 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: How to update a jar?
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 May 2001 12:57:19 +0100
Message-ID: <C50684A447AC9E4DB8D7C5C180A61A7C18A527@bluenote.peramon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How to update a jar?
Thread-Index: AcDZRWjjfgBvy57SRNWebZCKQgddTAAAohnw
From: "Jon Skeet" <jon.skeet@peramon.com>
To: <ant-dev@jakarta.apache.org>
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

> Jon Skeet <jon.skeet@peramon.com> wrote:
>=20
> >> >> It is all coded up, using java.util.zip classes in Ant 1.3 and
> >> >> using a new org.apache.tools.zip package in Ant 1.4alpha.
> >> >=20
> >> > Okay, that presumably makes it a right royal pain to attempt to
> >> > write a patch to allow this
> >>
> > The "pain" is patching two sets of source code :)
>=20
> Then don't do that ;-), we just need a patch against the current CVS
> version to include it in Ant 1.4.

Ah, but I'm using 1.3 at the moment, so it's easiest to develop it
against
that :)

(Hopefully the difference shouldn't be too big, however.)
=20
> > Right. My initial thought was to have a protected
> > getUpdateZipFileSet method and override it in subclasses
>=20
> But please make this optional.  I know we could always tell people
> they should use <zip> if they want to include the original manifest
> file, but a lot of users are not even aware that a .jar file is a zip
> file.

I'm not sure what you mean by optional in this case... the user wouldn't
have to specify anything in this case - it would all be hard-coded in=20
the relevant classes (with zip just returning an "include everything"
ZipFileSet). If the user wanted a specific manifest entry, they'd have
to specify the manifest themselves for the moment - I'll look into
other possibilities, but for the time being it's much easier to just
completely ignore the original manifest.

Jon