Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jgit-dev] plexus-archiver as optional "jgit archive" dependency

Hi JGitters,

I have been working on the "jgit archive" command to support code
search and snapshot download links[*].  This isn't a core jgit
feature but just a nicety for most users, I suspect.

While teaching it to handle recording executables and symlinks, I
noticed that the JVM's built-in ZipOutputStream class doesn't support
changing the "version made by" and "external file attributes"
fields.  That means it cannot write ZIP entries that will produce
executable files or symlinks when extracted with InfoZIP[**].  In the
OpenJDK source we see:

    /*
     * Write central directory (CEN) header for specified entry.
     * REMIND: add support for file attributes
     */

Plexus Archiver (org.codehaus.plexus:plexus-archiver on Maven
central, development repo at http://github.com/sonatype/plexus-archiver)
is a multi-format archiver library under the Apache License
version 2.0.  It can be used as a drop-in replacement for java.util.zip
and adds some nice features.  Most notably:

 * support for recording file mode
 * support for other formats like tar

It's a simple library and proven to work well, as the backend used
by Maven to write ZIP files and tarballs.

What would you think of teaching JGit to use plexus-archiver
opportunistically, as a "works-with" dependency?  If it seems like a
good idea, what's the first step?

Looking forward to your thoughts,
Jonathan

[*] In the long term I would like to move most of its functionality to
org.eclipse.jgit.api and to keep on adding features from "git archive"
(maybe even prototyping some features that are not in C git yet, like
setting timestamps according to the last commit that modified a file)
as time allows.

[**] The usual way to record the file mode in a ZIP file is by setting
the upper byte of the "version made by" to 3 (UNIX) and the upper two
bytes of "external attributes" to the UNIX file mode.  An alternative
method is to include an "ASi extra block" describing the file mode,
but unfortunately InfoZIP does not check for the mode in the ASi extra
block unless the upper byte of "version made by" refers to one of a
list of UNIX-y platforms, instead of 0 as in ZIP files written by
java.util.zip.ZipOutputStream.


Back to the top