Как отлаживать замену артефакта в Maven

Question

У меня есть родительский проект, содержащий десяток дочерних проектов, один из дочерних проектов использует org.apache.httpcomponents:httpclient:jar:4.3.5, что зависит от org.apache.httpcomponents:httpcore:jar:4.3.2.

Однако итоговая версия httpcore разрешена к 4.2.1 вместо 4.3.2.

Следующая является извлечение выхода при запуске dependency:tree с опцией отладки проверенного в Eclipse:

... 
[DEBUG] Using mirror nexus (http://192.168.0.111:8081/nexus/content/groups/public) for apache.snapshots (http://repository.apache.org/snapshots). 
[DEBUG] testArtifact: artifact=org.apache.httpcomponents:httpclient:jar:4.3.5:compile 
[DEBUG] includeArtifact: artifact=org.apache.httpcomponents:httpclient:jar:4.3.5:compile 
[DEBUG] startProcessChildren: artifact=org.apache.httpcomponents:httpclient:jar:4.3.5:compile 
[DEBUG]  manageArtifactVersion: artifact=org.apache.httpcomponents:httpcore:jar:4.3.2:compile, replacement=org.apache.httpcomponents:httpcore:jar:4.2.1 
[DEBUG] Using mirror nexus (http://192.168.0.111:8081/nexus/content/groups/public) for apache.snapshots (http://repository.apache.org/snapshots). 
... 

Это просто показывает replacement=org.apache.httpcomponents:httpcore:jar:4.2.1, но это ничего не говорит о причине замены. В pom.xml родительского проекта используется довольно много зависимостей, и хотя я мог бы попытаться удалить эти зависимости один за другим и проверить результат, это займет много времени. Есть ли более эффективный способ отладки замены артефакта?

---

Here почти полный логарифм dependency:tree из Eclipse, с опцией отладки проверяемого.

Answer 1

Из вашего журнала, вы можете найти следующие строки:

[DEBUG] com.company.xyz:xyz-integration-lib:jar:0.0.1-SNAPSHOT 
[DEBUG] com.company.xyz:xyz-utils:jar:0.0.1-SNAPSHOT:compile 
[DEBUG]  commons-codec:commons-codec:jar:1.8:compile 
[DEBUG] javax.mail:mail:jar:1.4:provided 
[DEBUG]  javax.activation:activation:jar:1.1.1:provided (version managed from 1.1 by org.jboss.spec:jboss-javaee-6.0:3.0.2.Final) 
[DEBUG] org.apache.commons:commons-lang3:jar:3.3.2:compile 
[DEBUG] junit:junit:jar:4.8.2:test 
[DEBUG] com.thoughtworks.xstream:xstream:jar:1.4.7:compile 
[DEBUG]  xmlpull:xmlpull:jar:1.1.3.1:compile 
[DEBUG]  xpp3:xpp3_min:jar:1.1.4c:compile 
[DEBUG] joda-time:joda-time:jar:2.4:compile 
[DEBUG] org.assertj:assertj-joda-time:jar:1.1.0:test 
[DEBUG]  org.assertj:assertj-core:jar:1.3.0:test 
[DEBUG] org.apache.httpcomponents:httpclient:jar:4.3.5:compile 
[DEBUG]  org.apache.httpcomponents:httpcore:jar:4.2.1:compile (version managed from 4.3.2 by org.jboss.as:jboss-as-parent:7.2.0.Final) 
[DEBUG] commons-logging:commons-logging:jar:1.1.3:compile 
[DEBUG] org.slf4j:slf4j-api:jar:1.7.7:compile 
[DEBUG] org.slf4j:slf4j-log4j12:jar:1.7.7:compile 
[DEBUG]  log4j:log4j:jar:1.2.17:compile 
[DEBUG] org.mockito:mockito-all:jar:1.9.5:test 
[DEBUG] org.powermock:powermock-module-junit4:jar:1.5.5:test 
[DEBUG]  org.powermock:powermock-module-junit4-common:jar:1.5.5:test 
[DEBUG]   org.powermock:powermock-core:jar:1.5.5:test 
[DEBUG]    org.javassist:javassist:jar:3.18.1-GA:test (version managed from 3.18.2-GA by org.springframework.boot:spring-boot-dependencies:1.1.4.RELEASE) 
[DEBUG]   org.powermock:powermock-reflect:jar:1.5.5:test 
[DEBUG]    org.objenesis:objenesis:jar:2.1:test 
[DEBUG] org.powermock:powermock-api-mockito:jar:1.5.5:test 
[DEBUG]  org.powermock:powermock-api-support:jar:1.5.5:test 

Где вы можете увидеть, что javassist и httpcore версий отбрасываются некоторыми переходными зависимостями и javax.activation версии увеличиваются на один.

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

Правила медиации от Maven docs являются следующие:

Dependency посредничество - это определяет, какая версия зависимости будет использоваться, когда несколько версий артефактов встречаются. В настоящее время Maven 2.0 поддерживает только «ближайшее определение» , что означает, что он будет использовать версию ближайшей зависимости от вашего проекта в дереве зависимостей. Вы всегда можете гарантировать версию , объявив ее явно в POM вашего проекта. Обратите внимание, что если две версии зависимостей находятся на одной и той же глубине в дереве зависимостей, , пока Maven 2.0.8 не определил, какой из них выиграть, но с Maven 2.0.9 это порядок в объявлении, который считается: первый Победа в объявлении.

«ближайшее определение» означает, что используемая версия будет самой близкой к вашему проекту в дереве зависимостей, например. если зависимости для A, B и C определены как A -> B -> C -> D 2.0 и A -> E -> D 1.0, тогда D 1.0 будет использоваться при построении A, поскольку путь от A до D через E короче. Вы можете явно добавить зависимость к D 2.0 в А, чтобы заставить использование D 2.0

Однако то, что вы можете сделать, это управлять версиями зависимостей самостоятельно.Это называется управление зависимостями и как указано одними и теми же документы:

Управление зависимостями - это позволяет авторам проекта напрямую указать версии артефактов, которые будут использоваться, когда они встречаются в зависимости переходных или в зависимости, где нет версия имеет . В примере в предыдущем разделе зависимость была непосредственно добавлена ​​к A, даже если она не используется непосредственно A. Вместо этого A может включать D в качестве зависимости в разделе управления зависимостями и непосредственно контролировать, какая версия D используется, когда , или если, , он всегда упоминается.

Таким образом, вы можете просто добавить:

<dependencyManagement> 
    <dependencies> 
    <dependency> 
     <groupId>bar</groupId> 
     <artifactId>foo</artifactId> 
     <version>1.2.3</version> 
    </dependency> 
    </dependencies> 
</dependencyManagement> 

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