Extract referenced slf4j bundle for Maven runtime classpath again #961
Conversation
This is necessary because even the slf4j-bundle from Maven-Central is jar-singed as part of the m2e build when the m2e-repo is assembled. If the slf4j-jar is not extracted launching the embedded maven-runtime will fail with errors like: ``` 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-api' jar and the 'maven-slf4j-provider' jar both provide classes for the package 'org.slf4j'. But all jars that provide classes for the same package must have the same jar-signer. And while the 'slf4j-api' jar is referenced as bundle and therefore signed in the m2e build (although it is originated from Maven-Central), the 'maven-slf4j-provider' jar embedded into the m2e.maven.runtime is not jar signed (because nested jars are not signed). Extracting the jar and providing them from a directory This check is not performed if a jar is extracted and added to the classpath as directory. Therefore only the slf4j jar is extracted again. Effectively this reverts commit 143c182 for slf4j. Additionally this ensures that paths to jars are canonicalized.
HannesWell
force-pushed
the
extractSLF4J
branch
from
1d0fb2c
to
84ec74b
Compare
|
I also considered to disable the signing of the third-party dependencies embedded into the m2e-repo (with are all from Maven-Central), but we have discussed this at the beginning of this year in #520 at not signing them was not an option back then. |
|
Embedded dependencies shouldn't be signed but should instead remain equals to upstream ones. jarsigner is required for bundles that are installable units in p2 and are built at Eclipse.org. This doesn't apply to slf4j or other embedded jars. |
The jars embedded for example into |
|
I'm going to submit this now in order to fix launching Maven builds using M2Es embedded Maven. |
It sounds like the dual symptom of what I expressed in #520 (comment) . If we sign the artifacts we produce, and not the sign content, then we wouldn't erroneously sign 3rd party content. |
Yes, if we would only sign each Maven-module/project we build and not the entire repo in the end, then this work-around would not be necessary. But at least in #520 (comment) it was stated that the latter is necessary. But if that is still true is what I'm wondering about. |
|
I think it this no longer required to sign third party jars (and maybe not third party ones?) so we can remove this from the m2e build and instead "sign" them using PGP... |
This is necessary because even the slf4j-bundle from Maven-Central is jar-singed as part of the m2e build when the m2e-repo is assembled.
If the slf4j-jar is not extraced launching the embedded maven-runtime will fail with errors like:
The reason for such an error is that the 'slf4j-api' jar and the 'maven-slf4j-provider' jar both provide classes for the package 'org.slf4j'. But all jars that provide classes for the same package must have the same jar-signer. And while the 'slf4j-api' jar is referenced as bundle and therefore signed in the m2e build (although it is originated from Maven-Central), the 'maven-slf4j-provider' jar embedded into the m2e.maven.runtime is not jar signed (because nested jars are not signed).
Extracting the jar and providing them from a directory This check is not performed if a jar is extracted and added to the classpath as directory. Therefore only the slf4j jar is extracted again. Effectively this reverts #926 for slf4j.