Maven: сначала разрешите зависимости, используя зависимости контейнера

Question

У меня есть plugin project, который добавляется к другим container projects в качестве зависимости.

Теперь этот проект плагина использует много частых зависимостей, таких как spring-security, commons-lang и т. Д.

Обычно контейнерные проекты содержат собственные версии таких частых зависимостей.Итак, когда мы добавляем нашу зависимость от плагина, возникают конфликты, и зависимости разрешаются на основе обычных maven dependency resolver и в зависимости от тегов scopes и optional, представленных в зависимостях проекта плагина.

Есть ли способгде все зависимости разрешаются сначала с использованием версии в родительских зависимостях, и если они недоступны, то используют версию, указанную в зависимости от плагина.

Примечание: необязательно и во время выполнения области возникает проблема, заключающаяся в том, что эти зависимости предоставляютсяконтейнера и, следовательно, преследует цель обеспечить беспроблемную одиночную зависимость для добавления зависимости плагина.

Answer 1

Предполагая, что ваши проекты контейнеров и плагинов используют один и тот же родительский pom, вы можете использовать раздел <dependencyManagement> в родительском элементе для определения общих артефактов.Это позволяет вам опустить версию в разделе плагинов <dependencies>.

родитель:

 <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>group-a</groupId>
        <artifactId>artifact-a</artifactId>
        <version>1.0</version>
      </dependency>
    </dependencies>
 </dependencyManagement>

плагин / модуль:

    <dependencies>
      <dependency>
        <groupId>group-a</groupId>
        <artifactId>artifact-a</artifactId>
      </dependency>
    </dependencies>

Подробнее см. https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.

Answer 2

В ваших плагинах pom определите версию зависимости как диапазон версий, которые вы знаете, чтобы плагин мог использовать.Если контейнер-зависимость перекрывается, это будет использоваться.Если не может быть найдена перекрывающаяся версия зависимости, как контейнера, так и плагина, будет выдана ошибка, так как согласование не удалось.Не используйте специальную область видимости для зависимостей, поскольку вы хотите, чтобы они при необходимости включались в контейнер,

См .:

https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

И:

https://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges

Answer 3

вы можете исключить его при создании проекта плагина и добавлении зависимости в maven.Это пример.Зависимость и основной проект конфликтовали из-за библиотеки журналов.Ниже следует исключить log4j в проекте зависимостей.

<dependency>
        <groupId>org.apache.zookeeper</groupId>
        <artifactId>zookeeper</artifactId>
        <version>${zk.version}</version>
        <exclusions>
            <exclusion>
                <groupId>log4j</groupId>
                <artifactId>log4j</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

P / S: Добавлено из моих комментариев: Я также разработал систему, которая имеет аналогичную архитектуру с вашей.Я делю эту систему на 3 основные части: 1. Commons, который содержит общий код и необходимые maven-зависимости, 2. Основной проект, 3. Проект плагина.Вы можете сослаться на это.