JGit api changed - Handling removal of methods from an underlying API

Mark Waite

unread,

Jun 21, 2016, 5:56:08 PM6/21/16

to Jenkins Developers

The git client plugin 2.0.0 and git plugin 3.0.0 releases will only support JDK 7 and later. The change to JDK 7 allows code simplifications (try with resources, etc.) and are a good opportunity to upgrade from embedding JGit 3 to embedding JGit 4.

JGit 4 only supports JDK 7 and later. The API's in JGit 4 have been reworked to support JDK 7 try with resources. That API rework is what allows the most significant code simplifications. However, that means there are some JGit 3 API calls which no longer exist in JGit 4 (JGit 3 has TreeWalk.release(), while JGit 4 TreeWalk does not have release()).

Now the challenge. The git client plugin intentionally bundles JGit so that other plugins can use JGit without bundling it themselves. However, a switch of the JGit version from JGit 3 to JGit 4 means that the JGit usage in plugins which depend on JGit as delivered by the git-client plugin may be broken by the upgrade from git client plugin 1 to git client plugin 2.

The scenarios I see can be illustrated with git client and git plugin (since the git plugin has the same problem as other JGit consumers may):

Git client plugin 1.19.6 with git plugin 2.4.4 -> allowed and works as expected (current configuration) (available to Jenkins versions 1.609 and later)

Git client plugin 1.19.6 with git plugin 3.0.0 -> not allowed because git plugin 3 explicitly depends on git client plugin 2

Git client plugin 2.0.0 with git plugin 2.4.4 -> allowed but will fail because git plugin 2 depends on at least one JGit 3 API call (available to Jenkins 1.625 and later)

Git client plugin 2.0.0 with git plugin 3.0.0 -> allowed and works as expected (available to Jenkins 1.625 and later)

I think I could remove the JGit TreeWalk dependency from the git plugin pretty easily, but I suspect there are other plugins which also depend on JGit and which may be harmed by the change from JGit 3 to JGit 4.

Are there other, more effective techniques for managing this type of dependency problem? I like very much the benefits of Java 7 and of JGit 4, but would like to not break compatibility for other plugins.

Alternately, I could search the plugin tree for JGit references to see the actual scope of the problem. I haven't detected any other JGit 3 specific dependencies in my integration testing (git plugin, github plugin, GitHub Organization Folders, various workflow uses, etc.), but my failure to detect those dependencies doesn't mean they don't exist... In my first attempt (searching just for TreeWalk), I found that git plugin and openshift-deployer-plugin both depend on JGit TreeWalk(). Two consumers (one of which I maintain, the other which seems to include its own specific JGit version) is not enough to spend much effort trying to retain compatibility.

Thanks,

Mark Waite

Stephen Connolly

unread,

Jun 21, 2016, 6:06:01 PM6/21/16

to jenkin...@googlegroups.com

Such a pity that they didn't change the package name when breaking backwards compatibility...

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/40211832-a315-43e6-8372-94fb21109e5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Stephen Connolly

unread,

Jun 21, 2016, 6:06:29 PM6/21/16

to jenkin...@googlegroups.com

OTOH they are OSGi people, so they don't have to worry about that problem

Björn Pedersen

unread,

Jun 22, 2016, 5:01:53 AM6/22/16

to Jenkins Developers

At least gerrit-trigger-plugin up to 2.21.1 uses TreeWalk.release.

Robert Sandell

unread,

Jun 22, 2016, 5:21:17 AM6/22/16

to jenkin...@googlegroups.com

On Wed, Jun 22, 2016 at 11:01 AM, 'Björn Pedersen' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

At least gerrit-trigger-plugin up to 2.21.1 uses TreeWalk.release.

Really? Where? I found usage of RevWalk but not TreeWalk.

/B

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ac10b570-bb2c-47d0-97b6-390602e464e6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

Björn Pedersen

unread,

Jun 22, 2016, 5:46:48 AM6/22/16

to Jenkins Developers

Am Mittwoch, 22. Juni 2016 11:21:17 UTC+2 schrieb Robert Sandell:

On Wed, Jun 22, 2016 at 11:01 AM, 'Björn Pedersen' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
At least gerrit-trigger-plugin up to 2.21.1 uses TreeWalk.release.

Really? Where? I found usage of RevWalk but not TreeWalk.

You are right, it was RevWalk:

FATAL: org.eclipse.jgit.revwalk.RevWalk.release()V
java.lang.NoSuchMethodError: org.eclipse.jgit.revwalk.RevWalk.release()V
	at com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser$1.invoke(GerritTriggerBuildChooser.java:185)
	at com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser$1.invoke(GerritTriggerBuildChooser.java:166)
	at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:27)

Jesse Glick

unread,

Jun 22, 2016, 1:43:27 PM6/22/16

to Jenkins Dev

On Tue, Jun 21, 2016 at 5:56 PM, Mark Waite <mark.ea...@gmail.com> wrote:
> I could search the plugin tree for JGit references to see the
> actual scope of the problem.

I would start there, especially if you have a complete list of
exhaustive members you could search for usages of.

It would be very helpful if someone (hint hint Andres) were to
routinely run `plugin-compat-tester` against all (@jenkinsci) trunk
plugins with trunk dependencies, so we would at least find any
regressions promptly. Also perhaps someone could resurrect Sorcerer
and get it running on the @jenkinsci code base so we could quickly
find method usages, even when they are of generic-sounding names like
`release`.

Robert Sandell

unread,

Jul 6, 2016, 9:43:56 AM7/6/16

to jenkin...@googlegroups.com

I have released Gerrit trigger 2.22.0-beta-1, thanks to a helpful contribution, with the needed JGit 4 changes for users to try out.

A helpful ping when Git Plugin 3 is released to main update center would be nice, so I can do the same.

/B

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr24PiF6Lyp1VF75DpQgnreCWLvoRNdzv8YErw8cyOJWSA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Mark Waite

unread,

Jul 6, 2016, 1:58:45 PM7/6/16

to Jenkins Developers

Will do. My current goal is to investigate other ways of resolving the issue without requiring that every plugin which depends on JGit must update at the same time.

For example, one of the experiments I hope to perform is to see if a dependent plugin could catch the runtime exception due to the missing release() method, and then use introspection to find and call the close() method.

I also have the goal to release git plugin 3.0 and git client plugin 2.0 before Jenkins World in September. Beta testing has been positive, with this JGit API change being the biggest hurdle detected to date.

Mark Waite

unread,

Jul 27, 2016, 12:19:22 AM7/27/16

to Jenkins Developers

I've posted a possible alternative as a pull request to the git plugin.

The alternative tries to call the JGit 3 implementation. If a NoSuchMethodError exception is raised, it uses reflection to find the close method (from JGit 4), and calls it (if it finds it).