-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't extract referenced bundles for Maven runtime classpath #926
Conversation
Unfortunately with this solution launching a maven build fails with:
This is because the org.slf4j.api bundle comes from Orbit and is signed with the EF key, while the binding (the maven.sl4j.simple) comes from Maven-Central and is only PGP signed and not jar signed. I prepared a patch to do the migration for M2E already but that revealed that with logback-classic 1.2.11 (the last version that does not require slf4j 2) plus slf4j-api 1.7.36 the logback jars are also pulled in into a launched Maven build classpath because the 'connection' in the OSGi world is done via a Coincidentally I wanted to propose the latter anyways and collected the items I think that have to be done, but this requires some coordinated effort for all projects that use SLF4J. I plan to create a corresponding proposal/issue for Eclipse Platform at the weekend and maybe also post some hint at the cross-project mailing list. |
IIRC the bundle symbolicName are different for Orbit vs upstream SLF4J, so if you use a Require-Bundle, then there would be no risk of getting the wrong one, even in SimRel. |
But maybe this then slows down other parts where this is used? Maybe we simply should not call the critical code section in the UI thread? |
That's right, but it is a little bit more to consider. I have created a umbrella issue in eclipse-platform aggreagtor to discuss and coordinate more effort in that direction:
I don't expect slowdowns in other areas due to this change. Regarding the slf4j issue: |
8170e42
to
21d11e8
Compare
183fa54
to
e6f8afc
Compare
Fixes eclipse-m2e#923 OSGi bundles that are referenced by the m2e.maven.runtime bundle don't have to be extracted when added to the classpath of an about to be launched Maven build. Not extracting them significantly speeds up the launch of the first build after IDE start or opening the first time the Launch-Config dialog for Maven builds or the Maven Installation settings. Additionally ensure that slf4j from Maven-Central is used instead of the one from Orbit to prevent errors like the following when launching a Maven-build with the embedded runtime from the IDE: ``` class "org.slf4j.MavenSlf4jFriend"'s signer information does not match signer information of other classes in the same package ``` The reason for such an error is that the slf4j variant from Orbit is jar-signed by Eclipse, while 'slf4j' and 'maven-slf4j-provider' from Maven-Central is only PGP-signed (and not jarsigned). But because 'slf4j' and 'maven-slf4j-provider' provide classes for the package org.slf4j they must provide the same signer information. This check is not performed if a jar is extracted and added to the classpath as directory, but we don't want to do that anymore. slf4j-from Maven-central is enforced by specifing a lower bound of 1.7.31 for slf4j bundles, while Eclipse-Orbit only provides 1.7.30.
Great, it finally works. I also tested it in Eclipse launched from m2e-dev Eclipse. |
Fixes #923
OSGi bundles that are referenced by the m2e.maven.runtime bundle don't
have to be extracted when added to the classpath of an about to be
launched Maven build. Not extracting them significantly speeds up the
launch of the first build after IDE start or opening the first time the
Launch-Config dialog for Maven builds or the Maven Installation
settings.
Additionally ensure that slf4j from Maven-Central is used instead of the
one from Orbit to prevent errors like the following when launching a
Maven-build with the embedded runtime from the IDE:
The reason for such an error is that the slf4j variant from Orbit is
jar-signed by Eclipse, while 'slf4j' and 'maven-slf4j-provider' from
Maven-Central is only PGP-signed (and not jarsigned). But because
'slf4j' and 'maven-slf4j-provider' provide classes for the package
org.slf4j they must provide the same signer information. This check is
not performed if a jar is extracted and added to the classpath as
directory, but we don't want to do that anymore.
slf4j-from Maven-central is enforced by specifing a lower bound of
1.7.31 for slf4j bundles, while Eclipse-Orbit only provides 1.7.30.