See
http://spring.io/blog/2008/10/20/understanding-the-osgi-uses-directive/

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

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

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

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

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

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

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

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

OSGi 4.01 comes with package org.osgi.framework version 1.3 [1] which
has the BundleActivator interface needed by org.eclipse.jgit.archive.
OSGi 5.0 matches package org.osgi.framework version 1.7 [2].

[1] http://www.osgi.org/javadoc/r4v401/
[2] http://www.osgi.org/javadoc/r5/core/

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

Change-Id: I347e8a9a112d142ccef91cba1d6e997d645ca70a

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