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() <http://download.eclipse.org/jgit/site/3.7.1.201504261725-r/apidocs/org/eclipse/jgit/treewalk/TreeWalk.html>, while JGit 4 TreeWalk does not have release() <http://download.eclipse.org/jgit/site/4.3.1.201605051710-r/apidocs/org/eclipse/jgit/treewalk/TreeWalk.html> ). 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 <https://github.com/search?q=org%3Ajenkinsci+TreeWalk&type=Code> (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 -- 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 [email protected]. 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.
