Early JGit code used comments to inform the Eclipse formatter about
where to break lines and used final in the hope of making code faster.
The ArchiveCommand command implementation imitated that style.

Nowadays the project relies less on the Eclipse formatter and relies
more on Java having sane performance with local variables that are not
explicitly marked 'final'.  Removing the unnecessary empty comments and
'final' qualifiers makes this code more readable and more consistent
with recent JGit code.

Change-Id: I7a181432eda7e18bd32cf110d89c0efbe490c4f1
Signed-off-by: Jonathan Nieder <jrn@google.com>

This unnecessary import was introduced by 2ecc27d.

Change-Id: I5cb415de7e33428d9f95dfbe1e214ef24be9dad9
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

When encountering a submodule entry, "jgit archive" tries to write its
content verbatim as an entry to the archive, which fails with a
JGitInternalException wrapping a MissingObjectException because the
submodule repository commits are typically not part of the
superproject.

When a subproject is available (for example because it has been
checked out as a subdirectory of a superproject worktree), it would be
nice to recurse into it and make one archive recording the state of
the entire project.  Unfortunately sometimes the subproject is not
available or it can be hard to find (e.g., it can be on another
server).  Even when some subprojects are available, "jgit archive"
should not produce different output for the same tree depending on
which subprojects it has easy access to, so there is no obvious good
default behavior that recurses without relying on access to all
subprojects.

Instead, replace each submodule entry with a placeholder empty
directory.  "git archive" does the same.

Change-Id: I1295086037b77fc948b3f93c21d47341e25483e5
Signed-off-by: Jonathan Nieder <jrn@google.com>

Entries for directories are optional and mostly wasted space in most
archive formats (except as a place to hang ownership and filesystem
permissions), but "git archive" includes them.  Follow suit.

This will make it easier in a later change to include empty
directories as placeholders for missing submodules.

Change-Id: I1810c686bcc9eb4d73498e4d3e763e18787b088a
Signed-off-by: Jonathan Nieder <jrn@google.com>

Common practice when distributing tarballs is to prefix all entries
with a single directory name so when the tarball is extracted it all
falls neatly into a single directory.  Add a setPrefix() method to
ArchiveCommand to support this.

Change-Id: I16b2832ef98c30977f6b77b646728b83d93c196f
Signed-off-by: Jonathan Nieder <jrn@google.com>

If the --format option is not given and the output filename is,
then infer the format from that filename.  Otherwise match
"git archive" by defaulting to tar (this is a change from the
existing "jgit archive" default behavior, which was to default to
zip).

Change-Id: I5806bc48a403d05e4cfc3c180b82b33ad7cfae7f

Attempts to write entries with too-long filenames currently error out:

  $ jgit.pgm/target/jgit archive HEAD >test.tar
  java.lang.RuntimeException: file name 'org.eclipse.jgit.http.server/src/org/eclipse/jgit/http/server/resolver/DefaultReceivePackFactory.java' is too long ( > 100 bytes)
          at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:288)
          at org.eclipse.jgit.archive.TarFormat.putEntry(TarFormat.java:92)
          at org.eclipse.jgit.archive.TarFormat.putEntry(TarFormat.java:62)
          at org.eclipse.jgit.api.ArchiveCommand.writeArchive(ArchiveCommand.java:293)
          at org.eclipse.jgit.api.ArchiveCommand.call(ArchiveCommand.java:322)
          at org.eclipse.jgit.pgm.Archive.run(Archive.java:97)
          at org.eclipse.jgit.pgm.TextBuiltin.execute(TextBuiltin.java:174)
          at org.eclipse.jgit.pgm.Main.execute(Main.java:213)
          at org.eclipse.jgit.pgm.Main.run(Main.java:121)
          at org.eclipse.jgit.pgm.Main.main(Main.java:95)

That's because the default longFileMode is LONGFILE_ERROR, which
throws an exception for filenames longer than 100 characters.  Switch
to LONGFILE_POSIX.  While at it, handle large files and filenames with
strange encodings, too.

This requires commons compress 1.4, which introduced support for large
files and POSIX long filenames.

Change-Id: I04d5427eec0968b129f55d7a4c6021039a494828

First step toward making ArchiveCommand itself format-agnostic.

Change-Id: I3cff5fce28fa7a19e34f8291cfb5b62f16429713

Unlike ZIP files, tar files do not treat symlinks as ordinary files
with a different mode, so tar support involves a little more code than
would be ideal.

Change-Id: Ica2568f4a0e443bf4b955ef0c029bc8eec62d369

Setting the mode for a zip entry is now as simple as
"entry.setUnixMode(mode)", so do that.

The test checks using the system's "zipinfo" command (from InfoZIP)
that the mode has been recorded correctly on systems that happen to
have a "zipinfo" command, using org.junit.Assume to distinguish them.

Change-Id: I4236c102fd76f18d01b2dc926eeb9b9fa11a61b7

C Git's "git archive" command represents a tree object using a
standard archival format like tar, zip, or tgz, ready for consumption
by other, git-unaware users or tools.

Add a bare-bones analagous "jgit archive" command to show what is
possible, supporting only ZIP format for now.  It uses java.util.zip
which is not aware of the InfoZIP extensions for representing symlinks
and file permissions, so symlinks, executable files, and submodule
entries are represented as plain text files.

Making this functionality available from the library, improving
handling of special entries, and support for other output formats are
left for later patches.  Ultimately the intent is to offer a
TreeArchiveStream class for use by web frontends like Gitiles to offer
"download as zip/tgz/txz" links and use by, for example, code search
tools to get easy access to the content of git tree objects.

Test with "jgit archive my-favorite-tree >out.zip".

Change-Id: Ib590f173ceff3df4b58493cecccd6b9a1b355e3d