Что мне делать с конфликтами зависимостей при использовании плагина maven-shade?

Question

Я использую maven-shade-plugin для создания исполняемого банку, который содержит все зависимости моего проекта. Иногда эти зависимости приводят к собственным зависимостям, которые сталкиваются с зависимостями других библиотек, а плагин maven-shade предупреждает меня, что он не уверен, какую версию включить в банку uber.

[WARNING] maven-shade-plugin has detected that some .class files 
[WARNING] are present in two or more JARs. When this happens, only 
[WARNING] one single version of the class is copied in the uberjar. 
[WARNING] Usually this is not harmful and you can skeep these 
[WARNING] warnings, otherwise try to manually exclude artifacts 
[WARNING] based on mvn dependency:tree -Ddetail=true and the above 
[WARNING] output 

В общем, мой ответ на это предупреждение, чтобы использовать <exclusions> элемент декларации в зависимости в моем файле пом, чтобы удалить зависимости обижая из моего проекта:

<!-- Amazon ElastiCache Client --> 
<dependency> 
    <groupId>com.amazonaws</groupId> 
    <artifactId>elasticache-java-cluster-client</artifactId> 
    <version>1.0.61.0</version> 
    <exclusions> 
     <!-- this junit dependency clashes with our test-scoped one and causes integration tests to fail to run --> 
     <exclusion> 
      <groupId>junit</groupId> 
      <artifactId>junit-dep</artifactId> 
     </exclusion> 
     <!-- this dependency brings in two versions of cglib that clash with one another --> 
     <exclusion> 
      <groupId>jmock</groupId> 
      <artifactId>jmock-cglib</artifactId> 
     </exclusion> 
     <!-- newer versions of these dependencies come with dropwizard-core --> 
     <exclusion> 
      <groupId>log4j</groupId> 
      <artifactId>log4j</artifactId> 
     </exclusion> 
     <exclusion> 
      <groupId>commons-logging</groupId> 
      <artifactId>commons-logging</artifactId> 
     </exclusion> 
     </exclusions> 
</dependency> 

Когда я делаю это, Я использую mvn dependency:tree, чтобы удостовериться, что я исключаю нижнюю версию оскорбительной зависимости, в надежде, что самая новая версия является самой зрелой и без ошибок.

Случаи, как один выше, что в конечном итоге с большим количеством исключений поднять два вопроса об этой практике:

1. В приведенном выше примере, почему я должен вручную исключить JUnit и JMock? Обе эти зависимости отмечены как <scope>test</scope> в the elasticache-java-cluster-client pom.xml, поэтому я ожидаю, что они не будут включены в банку, которую я получаю от maven.
2. Хотя моя практика всегда принимать более новую версию зависимости, похоже, до сих пор работает, я боюсь, что на днях я что-то сломаю. Есть ли лучший способ определить, какую версию зависимости сохранить?

Answer 1

Вы пробовали добавить maven-enforcer-plugin с DependencyConvergence rule? Это хорошо сработало для меня в сочетании с плагином. Он расскажет вам, какие артефакты приносят разные версии одних и тех же классов. Это позволило мне выяснить, что я должен исключить.

 <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-enforcer-plugin</artifactId> 
      <executions> 
       <execution> 
        <id>enforce</id> 
        <configuration> 
         <rules> 
          <DependencyConvergence/> 
         </rules> 
        </configuration> 
        <goals> 
         <goal>enforce</goal> 
        </goals> 
       </execution> 
      </executions> 
     </plugin>