0

In my Maven/Tycho build, I have a exec-maven-plugin that fails with a SecurityException caused by mismatching signer info in the org.eclipse.emf.common package. The exec-maven-plugin execution depends on two artifacts (actually more, but I think they are irrelevant for this issue):

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.4.0</version>
    <executions>
    ...
    </executions>
    <configuration>
        ...
        <includeProjectDependencies>false</includeProjectDependencies>
        <includePluginDependencies>true</includePluginDependencies>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.eclipse.xtext</groupId>
            <artifactId>org.eclipse.xtext.common.types</artifactId>
            <version>${xtext.version}</version>
        </dependency>
        <dependency>
            <groupId>my.group</groupId>
            <artifactId>my.group.artifact</artifactId>
            <version>1.8.6-SNAPSHOT</version>
        </dependency>
        ...
    </dependencies>
</plugin>

my.group.artifact is an OSGi project built with Tycho. As such, its dependencies get 'repackaged' during the build and installed into the local m2 repo under the p2.eclipse-plugin groupId.

The offending package org.eclipse.emf.common is a dependency of both org.eclipse.xtext.common.types and my.group.artifact but it gets resolved differently, as indicated by Maven (irrelevant dependencies omitted):

[DEBUG] org.codehaus.mojo:exec-maven-plugin:jar:1.4.0:
[DEBUG]    org.eclipse.xtext:org.eclipse.xtext.common.types:jar:2.12.0:runtime
[DEBUG]       org.eclipse.xtext:org.eclipse.xtext:jar:2.12.0:runtime
[DEBUG]          org.eclipse.emf:org.eclipse.emf.common:jar:2.15.0:runtime
[DEBUG]    my.group:my.group.artifact:jar:1.8.6-SNAPSHOT:runtime
[DEBUG]       p2.eclipse-plugin:org.eclipse.emf.common:jar:2.12.0.v20160420-0247:system

Then, when executing the above task, both jars are included and so the org.eclipse.emf.common package gets added to the classpath twice:

[DEBUG] Adding plugin dependency artifact: org.eclipse.emf.common to classpath
...
[DEBUG] Adding plugin dependency artifact: org.eclipse.emf.common to classpath

This results in the mentioned SecurityException:

java.lang.SecurityException: class "org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EScannableAdapterList"'s signer information does not match signer information of other classes in the same package

This is, presumably, because of the repackaging step described above.

What can I do to avoid this conflict?

End note: This is a build of a maintenance stream that worked successfully the last time it was run in July. Since then, there has only been a single, small code change that does not affect dependencies. However, the 2.15.0 version of org.eclipse.emf.common was released in September. Before that, 2.12.x was the latest release. xtext declares its dependency to emf with [2.10.0,3), which resolves to 2.15.0. Our artifact's target platform only includes 2.12.0. Of course, one thing to try now would be to move the target platform to 2.15.0 as well but I'm reluctant to do that because, as I said, this is a maintenance stream that should only receive necessary bug fixes.

Balz Guenat
  • 1,552
  • 2
  • 15
  • 35

1 Answers1

2

In this scenario, you could use exclusion and exclude the package from one the artifact/package as shown below

 <dependency>
     <groupId>my.group</groupId>
     <artifactId>my.group.artifact</artifactId>
     <version>1.8.6-SNAPSHOT</version>
     <exclusions>
         <exclusion>
             <groupId>org.eclipse.emf</groupId>
             <artifactId>org.eclipse.emf.common</artifactId>
         </exclusion>
     </exclusions>
 </dependency>
Vinoth A
  • 1,099
  • 9
  • 10
  • This didn't really work but it lead me on the right path. Even if I exclude `org.eclipse.emf:org.eclipse.emf.common` from `my.group.artifact`, it will still be pulled in by xtext. Then I tried excluding the Tycho version of the package, i.e. `p2.eclipse-plugin:org.eclipse.emf.common`. This fixed the SecurityException issue but revealed other issues related to versions. Other p2.eclipse-plugin dependencies masked newer versions from org.eclipse.emf. I had to extend the exclusions to `p2.eclipse-plugin:*` to get it to work. – Balz Guenat Oct 17 '18 at 10:12