Egit can't be used with 4.31 platform
iloveeclipse opened this issue · comments
Version
Latest nightly
Operating System
Linux/Unix
Eclipse version
Latest nightly 4.31
Bug description
I've started latest 4.31 build from https://download.eclipse.org/eclipse/downloads/drops4/I20231207-1800/ today installed latest Egit nightly and saw immediately that pull from upstream doesn't work anymore (and most likely push etc). There will be ClassNotFound exceptions thrown by jgit (will upload stack tomorrow).
The problem is missing slf4j if using apache client. Switching to native Java client in preferences fixes the problem.
I believe I saw some discussions about SSL support in jgit and most likely some recent change broke that now...
Actual behavior
Errors logged, functionality broken.
Expected behavior
It should work.
Relevant log output
No response
Other information
No response
4.31 SDK includes sfl4j-api and slf4j-simple 2.0.9. In JGit bundles have Import-Package for org.slf4j;version="[1.7.0,2.0.0)". The upper bound should probably be bumped to 3.0.0?
The SSL discussion would be eclipse-jgit/jgit#1.
According to https://www.slf4j.org/faq.html#changesInVersion200 slf4j 2.x should be API-compatible with 1.7.x.
In Apache MINA sshd we bumped the upper bound to 3.0.0 a while back and never got any complaints.
For OSGi runtime slf4j 2.x pulls in apache aries spifly which pulls in asm.
https://aries.apache.org/documentation/modules/spi-fly.html
I think adding so many dependencies just for logging sucks.
For now I added these dependencies to
https://eclipse.gerrithub.io/c/eclipse-jgit/jgit/+/1173385
Maybe we should consider to switch to another logging API.
How about Google's flogger which is used in Gerrit ?
https://github.com/google/flogger
https://google.github.io/flogger/
Eclipse platform does include spi-fly. We don't need to bump our slf4j in the target platform, we just need to set the upper bound to 3.0.0 in the manifests.
That way, it can be used with slf4j 1.7.x, or with slf4j 2.x. OSGi users wanting to use slf4j 2.x are then responsible themselves for also having spi-fly in the platform.
One main question: why do we have support for two http clients (Apache/Java native)?
- Are they not 100% interchangeable, and one misses some features from another?
- Or is that only for those who use Eclipse on ancient JDK without native Java http client?
- If they are supposed to provide same functionality, can we remove Apache http client to reduce complexity?
why do we have support for two http clients
The Apache HTTP bundle pre-dates my involvement in JGit. I would think that originally it was done because it offered much more functionality than the HTTP support in Java 6 or 7 used back then.
In EGit we changed the default to Apache HTTP in 2019 for one reason: Java does not allow connecting to an HTTPS target site through an HTTP proxy requiring basic auth. Apache HTTP does. See https://eclipse.gerrithub.io/c/eclipse-egit/egit/+/150746 .
GerritHub change 1173385 was merged in JGit on 2023-12-23.
Cannot reproduce anymore with https://download.eclipse.org/eclipse/downloads/drops4/I20240108-1800 and EGit nightly, which at the time of testing installed EGit 6.9.0.202401092007 and JGit 6.9.0.202312230002.