Зависимость общего подключаемого модуля Maven разрешается по-разному из-за переупаковки Tycho, что приводит к исключению SecurityException - PullRequest
0 голосов
/ 15 октября 2018

В моей сборке Maven / Tycho у меня есть exec-maven-plugin, который завершается с ошибкой SecurityException, вызванной несовпадением информации подписавшего в пакете org.eclipse.emf.common.Выполнение exec-maven-plugin зависит от двух артефактов (на самом деле больше, но я думаю, что они не имеют отношения к этой проблеме):

<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 - это проект OSGi, построенный с Tycho.Таким образом, его зависимости «переупаковываются» во время сборки и устанавливаются в локальный репозиторий m2 под p2.eclipse-plugin groupId.

Пакет-нарушитель org.eclipse.emf.common является зависимостью как org.eclipse.xtext.common.types, так и my.group.artifactно он решается по-разному, как указано Maven (нерелевантные зависимости опущены):

[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

Затем при выполнении вышеупомянутой задачи оба jar включаются, и поэтому пакет org.eclipse.emf.common добавляется в путь к классам дважды:

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

Это приводит к упомянутому исключению 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

Это, вероятно, из-за шага переупаковки, описанного выше.

Что я могу сделать дляизбежать этого конфликта?

Конечное примечание: это сборка потока обслуживания, которая работала успешно во время последнего запуска в июле.С тех пор произошло только одно небольшое изменение кода, которое не влияет на зависимости.Однако в сентябре была выпущена версия org.eclipse.emf.common 2.15.0.До этого 2.12.x была последней версией.xtext объявляет свою зависимость от emf с [2.10.0,3), который разрешается до 2.15.0.Целевая платформа нашего артефакта включает только 2.12.0.Конечно, сейчас нужно попробовать переместить целевую платформу на 2.15.0, но я не хочу этого делать, потому что, как я уже сказал, это поток обслуживания, который должен получать только необходимые исправления ошибок.

1 Ответ

0 голосов
/ 15 октября 2018

В этом сценарии вы можете использовать исключение и исключить пакет из одного артефакта / пакета, как показано ниже

 <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>
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...