Some of these eliminations just reduces the number of warnings on
lines where messages are constructed that can/will be translated.

Change-Id: I6eddb39ccc8f2488741bb58540d9ec5f5665e2c4

This should make it possible for the gitiles plugin to register its
archive formats after gerrit has already registered them.

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

This should make it easier to modify ArchiveCommand to allow an
archive format to be registered twice while still noticing if
different callers try to register different implementations for
the same format.

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

Change-Id: I6882c98c2785f38241a81ba5b93892aab79690a5

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>

This reverts commit 75d9b31f14.
Now that we do not try to close the ArchiveOutputStream in the error
path, there is no need to artificially close partial entries from
before the error.

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

Change-Id: I2f4c285d2b2f4bdb7a5d1a1026c131417066410d

Otherwise the underlying error is hidden by an "IOException: This
archives contains unclosed entries." when jgit tries to close the
archive.

Reported-by: Dave Borowitz <dborowitz@google.com>
Change-Id: I594dcdf366200b802e13e5a645fe06597feb7bb4
Signed-off-by: Jonathan Nieder <jrn@google.com>

Introduce a setFilename() method for ArchiveCommand so callers can
specify the intended filename of the produced archive.  If the
filename ends with .tar, the format will default to tar; if .zip, zip;
if .tar.gz, gzip-compressed tar; and so on.

This doesn't affect "jgit archive" because it doesn't support the
--output=<file> option yet.  A later patch might do that.

Change-Id: Ic0236a70f7aa7f2271c3ef11083b21ee986b4df5

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

Change-Id: Idb7ff75877a0cfe23f47e10e3f6f93386f5bb145

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

Document archive formats, the archive format interface, and the
parameters of the GitAPIException constructors.  Noticed by eclipse.

Reported-by: Dani Megert <Daniel_Megert@ch.ibm.com>
Change-Id: I22b5f9d4c0358bbe867c1906feec7c279e214273

Noticed by eclipse.

Change-Id: I730b290556066038efeaf2436de95415b175f351

This makes the functionality of registering all formats from the
org.eclipse.jgit.archive package available in contexts where
FormatActivator cannot be built because the OSGi core framework is not
readily available to build against.

Change-Id: If8e3487e933783a7e12f8e1838cbfe0b5862ce80

Change-Id: I347e8a9a112d142ccef91cba1d6e997d645ca70a

Add a static start() method to FormatActivator to allow outside
classes such as the Archive subcommand of the jgit program to use it
without a BundleContext.  This way, the list of formats only has to be
maintained in one place.

While at it, build a list of registered formats at start() time, so
stop() doesn't have to repeat the same list of formats.

Suggested-by: Shawn Pearce <spearce@spearce.org>
Change-Id: I55cb3095043568740880cc9e4f7cde05f49c363c

Allow use of ArchiveCommand without depending on the jgit command-line
tools.

To avoid complicating the process of installing and upgrading JGit,
this does not add a dependency by the org.eclipse.jgit bundle on
commons-compress.  Instead, the caller is responsible for registering
any formats they want to use by calling ArchiveCommand.registerFormat.

This patch puts functionality that requires an archiver into a
separate org.eclipse.jgit.archive bundle for people who want it.  One
can use it by calling ArchiveCommand.registerFormat directly to
register its formats or by relying on OSGi class loading to load
org.eclipse.jgit.archive.FormatActivator, which takes care of
registration automatically.

Once the appropriate formats are registered, you can make a tar or zip
from a git tree object as follows:

	ArchiveCommand cmd = git.archive();
	try {
		cmd.setTree(tree).setFormat(fmt).setOutputStream(out).call();
	} finally {
		cmd.release();
	}

Change-Id: I418e7e7d76422dc6f010d0b3b624d7bec3b20c6e