Maven: как переопределить зависимость, добавленную библиотекой - PullRequest
Новая
       5

Maven: как переопределить зависимость, добавленную библиотекой

96 голосов
/ 15 октября 2010

Вот моя общая проблема:

Мой проект P зависит от A, который зависит от B, который зависит от C, который зависит от версии 1.0.1 D.

Существует проблема с версией 1.0.1 D, и я хочу принудительно использовать другой модуль. Я не знаю, как объявить это в POM моего проекта, так как я не добавил зависимость от D напрямую. Это C, который объявил зависимость от D.

Важно: в этом случае меняется не только версия, но и группа и артефакт. Так что это не просто вопрос переопределения версии зависимости, а скорее исключения модуля и включения другого.

В конкретном случае D - это StAX, чья 1.0.1 имеет ошибку . Согласно примечаниям в сообщении об ошибке, «проблемы были решены путем замены stax-api-1.0.1 (maven GroupId = stax) на stax-api-1.0-2 (maven GroupId = javax.xml.stream)», поэтому я Я просто пытаюсь это сделать.

Таким образом, D = stax: stax-api: jar: 1.0.1 и C = org.apache.xmlbeans: xmlbeans: jar: 2.3.0

Я использую maven 2.0.9 на случай, если это имеет значение.

Вывод зависимости mvn: tree "

mvn dependency:tree
[..snip..]
[INFO] +- org.apache.poi:poi-ooxml:jar:3.6:compile
[INFO] |  +- org.apache.poi:poi-ooxml-schemas:jar:3.6:compile
[INFO] |  |  +- org.apache.xmlbeans:xmlbeans:jar:2.3.0:compile
[INFO] |  |  |  \- stax:stax-api:jar:1.0.1:compile

В POM моего проекта у меня есть следующая зависимость от «A»: 

<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi</artifactId>
    <version>3.6</version>
</dependency>
<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>3.6</version>
</dependency>

Заранее спасибо.

Ответы [ 4 ]

88 голосов
/ 15 октября 2010

Просто укажите версию в вашем текущем пом.Указанная здесь версия переопределит другую.

Форсирование версии
Версия всегда будет выполняться, если она объявлена ​​в текущем POM с определенной версией - однако,Следует отметить, что это также повлияет на другие poms вниз по течению, если оно само зависит от использования транзитивных зависимостей.

Ресурсы:

21 голосов
/ 07 февраля 2012

Кроме того, вы можете просто исключить нежелательную зависимость. STAX включен в JDK 1.6, поэтому, если вы используете 1.6, вы можете просто полностью исключить его.

Мой пример, приведенный ниже, немного не подходит для вас - вам нужно только одно из двух исключений, но я не совсем уверен, какое именно. Существуют и другие версии Stax, в моем примере ниже я импортировал A, который импортировал B, который импортировал C & D, и каждая (через еще более переходные зависимости) импортировала разные версии Stax. Поэтому в зависимости от «A» я исключил обе версии Stax. 

<dependency>
  <groupId>a.group</groupId>
  <artifactId>a.artifact</artifactId>
  <version>a.version</version>
  <exclusions>
    <!--  STAX comes with Java 1.6 -->
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>javax.xml.stream</groupId>
    </exclusion>
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>stax</groupId>
    </exclusion>
  </exclusions>
<dependency>
6 голосов
/ 24 мая 2016

У меня также были проблемы с переопределением зависимости в сторонней библиотеке. Я использовал подход Скотта с исключением, но я также добавил зависимость с более новой версией в pom. (Я использовал Maven 3.3.3)

Так что для примера stAX это будет выглядеть так: 

<dependency>
  <groupId>a.group</groupId>
  <artifactId>a.artifact</artifactId>
  <version>a.version</version>
  <exclusions>
    <!--  STAX comes with Java 1.6 -->
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>javax.xml.stream</groupId>
    </exclusion>
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>stax</groupId>
    </exclusion>
  </exclusions>
<dependency>

<dependency>
    <groupId>javax.xml.stream</groupId>
    <artifactId>stax-api</artifactId>
    <version>1.0-2</version>
</dependency>
3 голосов
/ 17 мая 2017

То, что вы поместите в тег </dependencies> корневого модуля, будет включено всеми дочерними модулями корневого модуля. Если все ваши модули используют эту зависимость, это путь.

Однако, если только 3 из 10 ваших дочерних модулей используют какую-либо зависимость, вы не хотите, чтобы эта зависимость была включена во все ваши дочерние модули. В этом случае вы можете просто поместить зависимость внутри </dependencyManagement>. Это гарантирует, что любой дочерний модуль, которому нужна зависимость, должен объявить его в своем собственном файле pom, но он будет использовать ту же версию этой зависимости, как указано в вашем теге </dependencyManagement>.

Вы также можете использовать </dependencyManagement> для изменения версии, используемой в переходных зависимостях, потому что будет использоваться версия, объявленная в самом верхнем файле pom. Это может быть полезно, если ваш проект A включает внешний проект B v1.0, который включает другой внешний проект C v1.0. Иногда случается, что в проекте C v1.0 обнаружена уязвимость, которая исправлена ​​в v1.1, но разработчики B не спешат обновлять свой проект для использования v1.1 of C. В этом случае вы можете просто объявить зависимость от C v1.1 в корневом каталоге вашего проекта внутри `, и все будет хорошо (при условии, что B v1.0 все еще сможет компилироваться с C v1.1).

...