e3798df6e8
OSGi can have its plugin localization at an arbitrary place; there is no need to have it in a top-level plugin.properties file. In non-OSGi environments having the files at the root level may mean that these files clash with each other, or, as in the referenced bug, with some third-party plug-in's plugin.properties, which may not even have anything to do with localization. Move our OSGi localization to a subfolder OSGI-INF/l10n. For OSGi environments, that's just as good, and for non-OSGi environments it avoid clashes with other root level items on the classpath or in a fat JAR. For fragments, use neither plugin.properties (which would clash with the host plug-in's plugin.properties) nor fragment.properties (which might clash with other fragments for the same fragment host bundle). Instead use names "relative" to the host bundle. Bug: 582394 Change-Id: Ifbcd046d912e2cfe86c0f7259c5ca8de599d9aa1 Signed-off-by: Thomas Wolf <twolf@apache.org> |
||
|---|---|---|
| .. | ||
| .settings | ||
| META-INF | ||
| OSGI-INF/l10n | ||
| resources | ||
| src/org/eclipse/jgit | ||
| .classpath | ||
| .fbprefs | ||
| .gitignore | ||
| .project | ||
| BUILD | ||
| README.md | ||
| about.html | ||
| build.properties | ||
| pom.xml | ||
README.md
JGit SSH support via JSch
This bundle provides an implementation of git transport over SSH implemented via JSch.
This bundle should be considered deprecated. It is essentially unmaintained, and the JGit project may decide anytime to remove it completely without further ado.
The officially supported SSH transport is in bundle org.eclipse.jgit.ssh.apache and is
built upon Apache MINA sshd.
Service registration
This bundle declares a service for the java.util.ServiceLoader for interface
org.eclipse.jgit.transport.ssh.SshSessionFactory. The core JGit bundle uses the service
loader to pick up an implementation of that interface. The bundle in an OSGi fragment
to ensure that the service loader works in an OSGi environment without the need to
install a service loader bridge.
Note that JGit simply uses the first SshSessionFactory provided by the ServiceLoader.
Using a different SSH implementation
To use a different SSH implementation:
- Do not include this bundle in your product.
- Include the bundle of the alternate implementation.
- If the service loader finds the alternate implementation, nothing more is needed.
- Otherwise ensure the service declaration from the other bundle is on the Classpath of bundle
org.eclipse.jgit, - or set the
SshSessionFactoryfor JGit explicitly (see below).
Configuring an SSH implementation for JGit
The simplest way to set an SSH implementation for JGit is to install it globally via
SshSessionFactory.setInstance(). This instance will be used by JGit for all SSH
connections by default.
It is also possible to set the SSH implementation individually for any git command
that needs a transport (TransportCommand) via a org.eclipse.jgit.api.TransportConfigCallback.
To do so, set the wanted SshSessionFactory on the SSH transport, like:
SshSessionFactory customFactory = ...; // Get it from wherever
FetchCommand fetch = git.fetch()
.setTransportConfigCallback(transport -> {
if (transport instanceof SshTransport) {
((SshTransport) transport).setSshSessionFactory(customFactory);
}
})
...
.call();
Using an external SSH executable
JGit has built-in support for not using any Java SSH implementation but an external SSH executable. To use an external SSH executable, set environment variable GIT_SSH to the path of the executable. JGit will create a sub-process to run the executable and communicate with this sub-process to perform the git operation.