Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] release 5.13.0

Dependabot detected a tag for JGit 5.13.0.  I've updated the Jenkins git client plugin to use JGit 5.13.0 in my test environment.

A new logging stack trace is being reported in the Jenkins git client plugin automated tests.  The stack trace is:

Sep 13, 2021 11:15:23 PM unlock
SEVERE: Unlocking LockFile '/tmp/junit14445476736651226115/junit15588760822522442699/.git/gc.log.lock' failed Could not delete file /tmp/junit14445476736651226115/junit15588760822522442699/.git/gc.log.lock
	at org.eclipse.jgit.util.FileUtils.handleDeleteException(
	at org.eclipse.jgit.util.FileUtils.delete(
	at java.base/
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.base/java.util.concurrent.ThreadPoolExecutor$
	at java.base/
Caused by: java.nio.file.NoSuchFileException: /tmp/junit14445476736651226115/junit15588760822522442699/.git/gc.log.lock
	at java.base/sun.nio.fs.UnixException.translateToIOException(
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(
	at java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(
	at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(
	at java.base/java.nio.file.Files.delete(
	at org.eclipse.jgit.util.FileUtils.delete(
	... 8 more

The stack trace surprises me, since a "no such file exception" when attempting to remove a lock file seems like it should not be logged as SEVERE.  If the lock file is gone, the lock has been released.  The logic at that location in org.eclipse.jgit/src/org/eclipse/jgit/util/ in the delete(File f, int options) method is more than I'm able to immediately understand.  Anyone have any insights to offer?

Mark Waite

On Tue, Sep 7, 2021 at 2:53 PM Mark Waite <mark.earl.waite@xxxxxxxxx> wrote:

On Tue, Sep 7, 2021 at 2:12 PM Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
Mark Waite <mark.earl.waite@xxxxxxxxx> wrote on Mo., 6. Sep. 2021, 18:53:
I'd prefer that December be 5.14 because the Jenkins project is not ready to abandon Java 8 yet and I believe that JGit 6.0 plans to drop Java 8.

I don't think there's anything forcing Jenkins or Jenkins plug-ins to use JGit 6.0 if they currently use 5.x and that works. So I don't quite understand the reasoning here.

Agreed that there is nothing forcing Jenkins to use JGit 6.0.  We'll remain with the 5.x line until Jenkins is ready to drop Java 8 support.  If past history is an indicator, that will be at least another 1-2 years.

I fully support the JGit project choosing their own timeline when they drop support for Java 8.

Jenkins has suffered some pain in the past when we allowed ourselves to fall behind the JGit development path.  The upgrade from JGit 4 to JGit 5 was quite laborious for the Jenkins git client plugin because it had to "catch up" across several minor versions and it had to resolve different API compatibility models used in JGit than are used in Jenkins.  There is nothing wrong with either of the API compatibility models, they are just different and the difference brought some complications.

Mark Waite
Personally, either is fine with me. When we do JGit 6.0 Java 11 based, EGit 6.0 will follow suit and will bump its baseline to Eclipse 2020-09. (First Eclipse version that required Java 11.)


jgit-dev mailing list
To unsubscribe from this list, visit

Back to the top