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
Provide static registerFormat and unregisterFormat methods to allow
formats to register themselves without the ArchiveCommand code being
aware of them.
Register the basic "zip" and "tar" support at bundle activation time
(and deregister them when unloading the bundle). For anyone using
this code as an OSGi plugin it should continue to just work.
The jgit program does not load org.eclipse.jgit.pgm as an OSGi bundle,
so let the Archive command register the formats it uses explicitly
with registerFormat.
Change-Id: Id39c03ea6923d0aed8316ed7b6bd04d5ced570a7
The most important difference is that in Java7 we have symbolic links
and for most operations in the work tree we want to operate on the link
itself rather than the link target, which the old File methods generally
do.
We also add support for the hidden attribute, which only makes sense
on Windows and exists, just since there are claims that Files.exists
is faster the File.exists.
A new bundle is only activated when run with a Java7 execution
environment. It is implemented as a fragment.
Tycho currently has no way to conditionally include optional features
based on the java version used to run the build, this means with this
change the jgit packaging build always needs to be run using java 7.
Change-Id: I3d6580d6fa7b22f60d7e54ab236898ed44954ffd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This breaks all existing callers once. Applications are not supposed
to build against the internal storage API unless they can accept API
churn and make necessary updates as versions change.
Change-Id: I2ab1327c202ef2003565e1b0770a583970e432e9
It stopped working when we moved to the Eclipse foundation's Gerrit
server since it doesn't use the Gerrit internal user store but LDAP.
Instead, since 2.0, we use the Eclipse foundation's automatic IP log
generator [1] to generate IP logs for releasing jgit and egit.
[1] http://www.eclipse.org/projects/ip_log_selector.php
Change-Id: I98dc65efb62909bc0258e6c680df0c93a57e9677
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The Apache Commons Compress library provides a similar interface to
java.util.zip with some features not found in java.util.zip, including
support for inclusion of metadata (file mode and symlink targets) and
support for multiple file formats (zip, .tar.xz, etc).
Use it, in preparation for making use of these features. No
functional change intended yet.
A previous version of this patch used plexus-archiver. That is a
heavier-weight dependency and offers a less convenient interface.
Thanks to James Moger and Chris Aniszczyk for advice.
Change-Id: Id01146950bb9c18dae0169311e3cde2c3bfa675e
This reverts commit 07f9936257.
07f9 seems to require a more recent args4j, but I cannot locate a CQ
that verifies we can use a version more recent then 2.0.12. 2.0.16
has been released, but the Hudson CI instance at Eclipse won't
build it.
Since the commit fixes an issue identified in March but wasn't
actually submitted to the tree until September, we can continue to
ignore whatever the problem is/was until someone can attempt a more
correctly working solution.
Change-Id: I94fa432c219bda21c1126976bb60e5292760092e
Use CmdLineException(CmdLineParser, String) instead. The new constructor
has been added in args4j 2.0.12, so in pom.xml that would be the minimum
version. Set the upper boundary in pom.xml to 2.1.0 (exclusive), just
like in the MANIFEST.MF.
Change-Id: If45d809e4ffa11a3572d958ce121422fb03cf8f3
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Orion wants to consume the pgm bundle from a p2 repository in their
build. Also add corresponding source bundle and feature to provision
sources via a target platform.
Bug: 373789
Change-Id: I0016ee155553c546606b63d310666eb10bd997e1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* stable-1.0:
Prepare post JGit v1.0.0.201106090707-r builds
JGit v1.0.0.201106090707-r
Include about.html files in maven build
Prepare post v1.0.0.201106081625-r builds
JGit v1.0.0.201106081625-r
Add missing about.html files to all shipped bundles
Prepare post v1.0.0.201106071701-r builds
JGit v1.0.0.201106071701-r
The strings are externalized into the root resource bundles.
The resource bundles are stored under the new "resources" source
folder to get proper maven build.
Strings from tests are, in general, not externalized. Only in
cases where it was necessary to make the test pass the strings
were externalized. This was typically necessary in cases where
e.getMessage() was used in assert and the exception message was
slightly changed due to reuse of the externalized strings.
Change-Id: Ic0f29c80b9a54fcec8320d8539a3e112852a1f7b
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
Since the API is changing relative to 0.7.0, we'll call our next
release 0.8.1. But until that gets released, builds from master
will be 0.8.0.qualifier.
Change-Id: I921e984f51ce498610c09e0db21be72a533fee88
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new plugin contains the bulk of the logic to scan a Git repository,
and query IPZilla, in order to produce an XML formatted IP log for the
requested revision of any Git based project. This plugin is suitable
for embedding into a servlet container, or into the Eclipse workbench.
The command line pgm package knows how to invoke this plugin through
the eclipse-iplog subcommand, permitting storage of the resulting
log as a local XML file.
Change-Id: If01d9d98d07096db6980292bd5f91618c55d00be
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Tycho isn't production ready for projects like JGit to be using as
their primary build driver. Some problems we ran into with Tycho
0.6.0 that are preventing us from using it are:
* Tycho can't run offline
The P2 artifact resolver cannot perform its work offline. If the
build system has no network connection, it cannot compile a
project through Tycho. This is insane for a distributed version
control system where developers are used to being offline during
development and local testing.
* Magic state in ~/.m2/repository/.meta/p2-metadata.properties
Earlier iterations of this patch tried to use a hybrid build,
where Tycho was only used for the Eclipse specific feature and P2
update site, and maven-bundle-plugin was used for the other code.
This build seemed to work, but only due to magic Tycho specific
state held in my local home directory. This means builds are not
consistently repeatable across systems, and lead me to believe
I had a valid build, when in fact I did not.
* Manifest-first build produces incomplete POMs
The POM created by the manifest-first build format does not
contain the dependency chain, leading a downstream consumer to
not import the runtime dependencies necessary to execute the
bundle it has imported. In JGit's case, this means JSch isn't
included in our dependency chain.
* Manifest-first build produces POMs unreadable by Maven 2.x
JGit has existing application consumers who are relying on
Maven 2.x builds. Forcing them to step up to an alpha release
of Maven 3 is simply unacceptable.
* OSGi bundle export data management is tedious
Editing each of our pom.xml files to mark a new release is
difficult enough as it is. Editing every MANIFEST.MF file to
list our exported packages and their current version number is
something a machine should do, not a human. Yet the Tycho OSGi
way unfortunately demands that a human do this work.
* OSGi bundle import data management is tedious
There isn't a way in the MANIFEST.MF file format to reuse the
same version tags across all of our imports, but we want to have
a consistent view of our dependencies when we compile JGit.
After wasting more than 2 full days trying to get Tycho to work,
I've decided its a lost cause right now. We need to be chasing down
bugs and critical features, not trying to bridge the gap between
the stable Maven repository format and the undocumented P2 format
used only by Eclipse.
So, switch the build to use Apache Felix's maven-bundle-plugin.
This is the same plugin Jetty uses to produce their OSGi bundle
manifests, and is the same plugin used by the Apache Felix project,
which is an open-source OSGi runtime. It has a reasonable number
of folks using it for production builds, and is running on top of
the stable Maven 2.x code base.
With this switch we get automatically generated MANIFEST.MF files
based on reasonably sane default rules, which reduces the amount
of things we have to maintain by hand. When necessary, we can add
a few lines of XML to our POMs to tweak the output.
Our build artifacts are still fully compatible with Maven 2.x, so
any downstream consumers are still able to use our build products,
without stepping up to Maven 3.x. Our artifacts are also valid as
OSGi bundles, provided they are organized on disk into a repository
that the runtime can read.
With maven-bundle-plugin the build runs offline, as much as Maven
2.x is able to run offline anyway, so we're able to return to a
distributed development environment again.
By generating MANIFEST.MF at the top level of each project (and
therefore outside of the target directory), we're still compatible
with Eclipse's PDE tooling. Our projects can be imported as standard
Maven projects using the m2eclipse plugin, but the PDE will think
they are vaild plugins and make them available for plugin builds,
or while debugging another workbench.
This change also completely removes Tycho from the build.
Unfortunately, Tycho 0.6.0's pom-first dependency resolver is broken
when resolving a pom-first plugin bundle through a manifest-first
feature package, so bundle org.eclipse.jgit can't be resolved,
even though it might actually exist in the local Maven repository.
Rather than fight with Tycho any further, I'm just declaring it
plugina-non-grata and ripping it out of the build.
Since there are very few tools to build a P2 format repository, and
no documentation on how to create one without running the Eclipse
UI manually by poking buttons, I'm declaring that we are not going
to produce a P2 update site from our automated builds.
Change-Id: If7938a86fb0cc8e25099028d832dbd38110b9124
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are on a Java 6 JVM we should have the Console class available,
unless the user has redirected /dev/null to stdin. When there is a
console present we would prefer to use that for command line prompts
as that is what the user expects from a command line tool.
Change-Id: Ibaf87bb5540371d94d96d1b7e94ca002f752e5bd
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Drop our simple and stupid jgit.sh and instead rely upon Maven
for the command line based build. Maven is relatively simple to
download and install, and doesn't require the entire Eclipse IDE.
To avoid too much refactoring of the current code we reuse the
existing src/ directory within each plugin, and treat each of
the existing OSGI bundles as one Maven artifact.
The command line wrapper jgit.sh no longer works in the uncompiled
state, as we don't know where to obtain our JSch or args4j from.
Developers will now need to compile it with `mvn package`, or run
our Main class from within an IDE which has the proper classpath.
Bug: 291265
Change-Id: I355e95fa92fa7502651091d2b651be6917a26805
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Matthias Sohn