Maven-shade-plugin, uber-jar и перекрывающиеся классы

Я хотел бы использовать Maven-shade-plugin для создания uber-jar. Но когда я вызываю mvn package команду Maven сообщает, что есть некоторые перекрывающиеся классы. Я связываю все проблематичные перекрытия, некоторые из них вызваны тем, что старые и новые версии библиотеки (Log4J), но некоторые из них, похоже, имеют одни и те же классы - например, javax.mail и mailapi/smtp/imap и так далее.

Что лучше делать в этой ситуации? Есть ли какой-то ключ, как решить, какое перекрытие безопасно игнорировать, которое должно быть правильным?

 - mailapi-1.4.3.jar, javax.mail-1.5.0.jar define 166 overlappping classes
 - spring-2.5.6.SEC03.jar, spring-tx-3.1.4.RELEASE.jar define 176 overlappping classes:
 - spring-beans-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 283 overlappping classes:
 - slf4j-log4j12-1.7.5.jar, slf4j-impl-2.0-beta2.jar define 3 overlappping classes:
 - spring-2.5.6.SEC03.jar, spring-context-support-3.1.4.RELEASE.jar define 55 overlappping classes:
 - aopalliance-1.0.jar, spring-2.5.6.SEC03.jar define 9 overlappping classes:
 - imap-1.5.0.jar, javax.mail-1.5.0.jar define 87 overlappping classes:
 - commons-logging-api-1.1.jar, commons-logging-1.1.3.jar define 19 overlappping classes:
 - spring-2.5.6.SEC03.jar, spring-core-3.1.4.RELEASE.jar define 161 overlappping classes:
 - spring-2.5.6.SEC03.jar, spring-context-3.1.4.RELEASE.jar define 326 overlappping classes: 
 - log4j12-api-2.0-beta3.jar, log4j-1.2.17.jar define 23 overlappping classes: 
 - spring-aop-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 237 overlappping classes:
 - spring-jdbc-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 239 overlappping classes:
 - quartz-1.8.6.jar, quartz-jobs-2.2.1.jar define 15 overlappping classes:
 - smtp-1.5.0.jar, javax.mail-1.5.0.jar define 17 overlappping classes: 
 - spring-asm-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 31 overlappping classes:

EDIT: это приложение "A" использует в качестве зависимости от Maven мое другое приложение Java - я назову это приложение "B". Это приложение B использует javax.mail ver 1.5.1. В этой библиотеке также используется первое приложение. Но когда я вызываю команду mvn package, Maven замечает, что javax.mail-api-1.5.1.jar, javax.mail-1.5.1.jar define 135 overlappping classes.

Является ли эта проблема, и если да, то как ее решить или я могу ее игнорировать?

Ответ 1

Первое, что нужно сделать, - удалить как можно больше очевидных причин перекрывающихся классов. Например:

У вас есть зависимости как от spring 2.5.6, так и от spring 3.1.4, что даст вам больше проблем, чем просто в плагине оттенков. Настройте зависимости вашего модуля, поэтому у вас есть только одна версия spring. Используйте исключения зависимостей, если вам нужно (скажем, что у вас есть транзитивные зависимости, которые вы не контролируете).
После того, как конфликты версии зависимостей исправлены, вы также можете настроить, какие банки переходят в uber-jar с конфигурацией плагина тени, как описано в http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html
Некоторые из фляг, вероятно, содержат все классы из их перекрывающихся банок.
- Я подозреваю, что commons-logging-1.1.3.jar имеет надмножество классов, объявленных в commons-logging-api-1.1.jar. Если это так, вы можете исключить api jar.
- В ответ на отредактированный вопрос, javax.mail-1.5.1.jar содержит надмножество классов в javax.mail-api-1.5.1.jar. Так как это явно одна и та же версия, и перекрывающиеся классы должны быть одинаковыми, это не повредит построению заштрихованной банки с перекрывающимися классами (она будет принимать классы из того, что она обрабатывает последним). Однако сборка будет более аккуратной и немного быстрее, если вы исключите api jar.

Невероятно, что вам нужно будет сохранить конфликтующие версии классов в затененной банке. Если вы это сделаете, плагин с оттенками также позволяет перемещать классы, как описано в http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

Ответ 2

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

$ **mvn dependency:tree -Dverbose -Dincludes=aopalliance**
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building petshop cli 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ cli ---
[INFO] com.sample.petshop:cli:jar:1.0
[INFO] \- **org.springframework:spring-context**:jar:4.1.3.RELEASE:compile
[INFO]    \- org.springframework:spring-aop:jar:4.1.3.RELEASE:compile
[INFO]       \- **aopalliance:aopalliance**:jar:1.0:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.865s
[INFO] Finished at: Fri May 08 15:12:01 IST 2015
[INFO] Final Memory: 14M/223M
[INFO] ------------------------------------------------------------------------

В байте aopalliance ссылается из spring -context-support, которая указывает, что мы могли бы исключить его.

Ответ 3

Этот вопрос дублирует этот, где вы можете найти больше примеров.

Но если вы уверены, что у вас нет перекрывающихся зависимостей (как и у меня), проект clean ing может помочь. Подробнее см. .