Как использовать банку с пружиной в качестве пакетной зависимости в другом проекте Spring с более высокой версией Spring?

Question

Существует множество вопросов о том, как добавить один весенний проект в качестве зависимости в другой весенний проект. Но я ищу решение конкретной проблемы c, как только мы успешно ответим на часть «Как».

Скажем, у нас есть два пружинных многомодульных проекта maven. Проект-А и Проект-Б. Версия SpringFramework, используемая в Project-A , равна 4.2.3 . Некоторые модули из Project-A объединены и встроены в uber-jar с использованием плагина-шейдера со специальной конфигурацией NO . Это означает, что если я открою uber-jar, я найду все зависимости (я думаю, что даже переходные зависимости) упакованы в uber-jar. (Конечно, это может быть некрасиво, но я не могу изменить этот uber-jar. Рефакторинг и разбивка его на более мелкие расходные зависимости не подлежат обсуждению по причинам x, y, z). Доступ к базовым ресурсам осуществляется через API, предоставляемые одним из модулей в uber-jar. Так что я застрял с этим.

Теперь я хочу использовать этот uber-jar из project-A в качестве зависимости в project-B. Я использовал плагин установки и приложил установку этого uber-jar во время фазы проверки.

Однако в Project-B я бы sh использовал spring-data-jdb c. Теперь spring-data-jdb c - это довольно новый проект, и, как описано здесь в ссылке do c, минимальная требуемая версия spring-framework - 5.2.6.RELEASE.

Поэтому, когда я добавил uber-jar в качестве зависимости, хотя я мог выполнить успешную чистую установку maven, я столкнулся с некоторым числом NoSuchMethodException, например: java.lang.nosuchmethoderror:org.springframework.util.reflectionutils.accessibleconstructor(ljava/lang/class;[ljava/lang/class;), когда артефакт был развернут в tomcat 8.5

Что похоже на проблему, описанную в этом вопросе. Поэтому, используя плагин зависимостей maven, я посмотрел на дерево зависимостей Project-B, но не увидел в списке Spring-версии 4.2.3. Под uber-jar не было перечислено никаких транзитивных зависимостей.

Я даже смотрел на путь к классу сборки под разными целями и все еще мог найти только весеннюю версию 5.2.6.RELEASE из Project-B в списке. Тем не менее, совершенно очевидно, что во время развертывания я использую только весеннюю ферму 4.2.3 из uber-jar. Поскольку метид, который не может быть найден, доступен только начиная с весны 5.0, как описано в java -do c здесь

Обновление весенней версии Project-A не возможно (опять же по причинам x, y, z). Я пытался исключить все зависимости из uber-jar при добавлении uber-jar в качестве зависимости, но это не помогло.

Вопросы:

1. Можем ли мы сказать проекту-B использовать зависимость Spring-Framework (5.2.6.RELEASE) своего проекта и не использовать его из uber-jar, пока позволить классам из проекта-A (в uber jar) использовать spring-framework, упакованный в uber-jar?
2. Это неприятно даже задавать вышеуказанный вопрос, потому что я думаю, что знаю, что обе версии добавляются в путь к классу. И во время развертывания контейнер выбирает первое, что он видит, вызывая эту проблему. Это правильно?
3. В описанной мною модели (например, построение uber-jar) как работает управление зависимостями? То есть, поскольку я вижу все зависимости, упакованные в uber-jar, когда я использую этот uber-jar в качестве зависимости, все ли упакованные зависимости (jars) также добавляются в путь к классам потребляющих проектов?
4. Я (maven) устанавливаю uber-jar во время сборки project-b на этапе проверки, а затем компилирую project-b, это вызывает проблему?
5. Если это не совсем верно, могу ли я получить рекомендация для альтернативы spring-data-jdb c? так что я могу полностью отказаться от идеи использования более высокой весенней версии в проекте-б. Мне не нужны все функции Java Persistence API, такие как отложенная загрузка, кэширование и все такое. Я просто хочу использовать шаблон репозитория, чтобы легко выполнять некоторые операции CRUD с простым управлением транзакциями, поэтому я выбрал spring-data-jdb c.

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

Обновление: поэтому дерево зависимостей будет выглядеть следующим образом:

• Project-A, дерево зависимостей модуля Uber-Jar

org.railomaya.uberJarModule:uberJar:jar:2.0
[INFO] +- org.railomaya:OtherModule_1:jar:2.0
[INFO] \- org.railomaya:OtherModule_2:jar:1.0:compile
[INFO] +- org.railomaya:otherModule_3:jar:1.0-SNAPSHOT:compile
[INFO] |  +- org.springframework:spring-jms:jar:4.2.3.RELEASE:compile
[INFO] |  |  +- org.springframework:spring-messaging:jar:4.2.3.RELEASE:compile
[INFO] |  |  \- org.springframework:spring-tx:jar:4.2.3.RELEASE:compile
[INFO] |  \- org.apache.activemq:activemq-spring:jar:5.13.2:compile
[INFO] +- org.springframework:spring-context-support:jar:4.2.3.RELEASE:compile
[INFO] |  +- org.springframework:spring-beans:jar:4.2.3.RELEASE:compile
[INFO] |  +- org.springframework:spring-context:jar:4.2.3.RELEASE:compile
[INFO] |  |  +- org.springframework:spring-aop:jar:4.2.3.RELEASE:compile
[INFO] |  |  |  \- aopalliance:aopalliance:jar:1.0:compile
[INFO] |  |  \- org.springframework:spring-expression:jar:4.2.3.RELEASE:compile
[INFO] |  \- org.springframework:spring-core:jar:4.2.3.RELEASE:compile
[INFO] |     \- commons-logging:commons-logging:jar:1.2:compile
[INFO] +- org.springframework.boot:spring-boot-starter:jar:1.5.1.RELEASE:compile
[INFO] |  +- org.springframework.boot:spring-boot:jar:1.5.1.RELEASE:compile
[INFO] |  +- org.springframework.boot:spring-boot-autoconfigure:jar:1.5.1.RELEASE:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter-logging:jar:1.5.1.RELEASE:compile
[INFO] |  |  +- ch.qos.logback:logback-classic:jar:1.1.9:compile
[INFO] |  |  |  \- ch.qos.logback:logback-core:jar:1.1.9:compile
[INFO] |  |  +- org.slf4j:jcl-over-slf4j:jar:1.7.22:compile
[INFO] |  |  +- org.slf4j:jul-to-slf4j:jar:1.7.22:compile
[INFO] |  |  \- org.slf4j:log4j-over-slf4j:jar:1.7.22:compile
[INFO] |  \- org.yaml:snakeyaml:jar:1.17:runtime
[INFO] +- org.springframework:spring-test:jar:4.2.3.RELEASE:test
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- org.apache.commons:commons-lang3:jar:3.3.1:compile
[INFO] +- commons-io:commons-io:jar:2.4:compile

Дерево зависимостей Project-B, где в качестве зависимости используется вышеуказанный uber-jar:

org.railomaya:project-B:war:2.0-SNAPSHOT
[INFO] +- org.railomaya.uberJarModule:uberJar:jar:2.0:compile
[INFO] +- org.apache.commons:commons-dbcp2:jar:2.0.1:compile
[INFO] |  \- commons-logging:commons-logging:jar:1.1.3:compile
[INFO] +- org.apache.commons:commons-pool2:jar:2.2:compile
[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.1:compile
[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.1:compile
[INFO] +- org.apache.logging.log4j:log4j-web:jar:2.1:compile
[INFO] +- javax.mail:mail:jar:1.4.5:compile
[INFO] |  \- javax.activation:activation:jar:1.1:compile
[INFO] +- javax.servlet:servlet-api:jar:2.5:provided
[INFO] +- mysql:mysql-connector-java:jar:5.1.26:compile
[INFO] +- org.quartz-scheduler:quartz:jar:2.2.1:compile
[INFO] |  +- c3p0:c3p0:jar:0.9.1.1:compile
[INFO] |  \- org.slf4j:slf4j-api:jar:1.6.6:compile
[INFO] +- org.springframework:spring-beans:jar:5.2.6.RELEASE:compile
[INFO] +- org.springframework:spring-context:jar:5.2.6.RELEASE:compile
[INFO] |  \- org.springframework:spring-aop:jar:5.2.6.RELEASE:compile
[INFO] +- org.springframework:spring-context-support:jar:5.2.6.RELEASE:compile
[INFO] +- org.springframework:spring-core:jar:5.2.6.RELEASE:compile
[INFO] |  \- org.springframework:spring-jcl:jar:5.2.6.RELEASE:compile
[INFO] +- org.springframework:spring-expression:jar:5.2.6.RELEASE:compile
[INFO] +- org.springframework:spring-jdbc:jar:5.2.6.RELEASE:compile
[INFO] +- org.springframework:spring-test:jar:5.2.6.RELEASE:test
[INFO] +- org.springframework:spring-tx:jar:5.2.6.RELEASE:compile
[INFO] +- org.springframework:spring-web:jar:5.2.6.RELEASE:compile
[INFO] \- org.springframework:spring-webmvc:jar:5.2.6.RELEASE:compile

Answer 1

Можем ли мы сказать проекту-B использовать зависимость Spring-Framework (5.2.6.RELEASE) своего проекта и не использовать зависимость из uber-jar, выпуская классы из проекта-A (в uber jar) использовать пружинные рамки, упакованные в uber-jar?

Не легко. См. Ниже.

Мне кажется, я знаю, что обе версии добавляются в путь классов. И во время развертывания контейнер выбирает первое, что он видит, вызывая эту проблему. Это правильно?

Да.

когда я использую этот uber-jar в качестве зависимости, все ли упакованные зависимости (jars) также добавляются в проекты-потребители classpath?

Да.

Я (maven) устанавливаю uber-jar во время сборки проекта -b на этапе проверки, а затем компилирую проект-b, это что вызывает проблему?

Да.

Если это не совсем верно, могу ли я получить рекомендацию по альтернативе spring-data-jdb c ?

Вы всегда можете использовать Springs JdbcTemplate и реализовать свои репозитории самостоятельно, используя его. Вы могли бы даже рассмотреть моделирование агрегатов, как это делает Spring Data JDB C.

Вернемся к первому вопросу:

Во-первых, давайте ясно дадим понять, что нет никакой гарантии, что Project A будет работать с более новыми Версия Spring, но давайте предположим, что это так.

Вам нужно разобрать ueber-jar, т.е. удалить все, что не является Project A, и установить его в хранилище maven, а затем зависеть от это также зависит от правильной версии (TM) Spring и всех других зависимостей.