[Deliberately cross-posted as a migration path from user to dev.
Apologies
for any confusion/offence caused.]
> Jon Skeet <[EMAIL PROTECTED]> wrote:
>
> >> 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.
> >
> > Okay, that presumably makes it a right royal pain to attempt to
> > write a patch to allow this (as a newbie when it comes to Ant
> > development).
>
> It depends on your experience. If you know the java.util.zip classes,
> its not that difficult (the new ones are an extension of ZipEntry and
> a new implementation of ZipOutputSteam with an interface identical to
> the standard one).
In fact it's not even that hard - I'm just going to create a new
ZipFileSet using the temporary file and call addFiles with that and the
new
zip file. The "pain" is patching two sets of source code :)
> > It strikes me it would be useful to allow this for zip as well as
> > jar, by the way.
>
> Sure. Jar is a child class of Zip, it just adds special treatment for
> the manifest file, that's all. All changes should happen for zip as
> <jar>, <war> and <ear> would benefit from them immediately.
>
> > There is one slight wrinkle, however: with the jar version I believe
> > you'd want to exclude the original manifest from the list of files
> > being added.
>
> Could be specified by using patterns - maybe jar would optionally
> exclude META-INF/MANIFEST.MF while war excludes WEB_INF/web.xml and so
> on.
Right. My initial thought was to have a protected getUpdateZipFileSet
method and override it in subclasses - does that seem reasonable, or
would
it be better just to have a getUpdateExclusion method which returned
the pattern to exclude?
> > Is there an easy way to effectively code up the bit of Ant XML
> > within the zip (or jar) task,
>
> take a look at the optional RenameExtension task in Ant 1.3, it simply
> maps itself to an invocation of move under the covers.
Right - yup, quite doable, but not much easier than using straight IO.
Nice
to see just as an example for any future tasks I might right though.
> > or would I be better off using the Java IO libraries directly for
> > the move/delete operations?
>
> I'd do so.
Goodo - as that's what I'm half-way through doing :) If anyone wants to
volunteer to help test it (and proof-read the code!) when I'm done, let
me
know off-list.
> > Oh, and at what stage is this discussion best moved to the Dev list?
>
> Four or five messages ago 8-)
LOL. Okay, I'll do the dirty and cross-post this one, then we can
continue
just on dev.
Jon