Maven и устаревшие зависимости. Как задать нужную версию?

Question

[Мира Рузвельт]

Всем привет.
На работе есть крупный многолетний сервис на Java 11 и Spring Boot 2.1
В очередной доработке надо было начать ходить в другие сервисы, интеграции в которые ранее не было.
Выбрал между RestTemplate и WebClient последний в виду его актуальности.

Локально поднять рабочий проект та еще задача - собрать все БД и системы куда уже он ходит и ждать пока выдадут сетевые доступы.
Для ускорения разработки создал свой новый локальный проект, протестировал и перенес новый код в рабочий проект сервиса.
И вот тут при компиляции вылез сюрприз - некоторые функции следующих классов помечались как несуществующие :

• import org.springframework.http.HttpHeaders; (артифакт spring-web)
  
• import reactor.netty.http.client.HttpClient; (артифакт reactor-netty)
  

Сразу выполнил :

• mvn clean
  
• переподтянул зависимости проекта
  
• mvn install
  
• очистил кеш Intellij IDEA с выгрузкой проекта и рестартом IDE
  

Ничего из этого не помогло.

Для использования WebClient необходимо подключить единственный артифакт spring-boot-starter-webflux.
Но оказалось, автоматически подтягиваются артифакты :

• spring-webflux
  
• reactor-netty
  

Когда сравнил версию этих артифактов (в тч spring-web) в рабочем проекте и моем тестовом - они различались, в моем проекте версии были на порядок выше.
Предположил, что это из-за того, что под артифактом spring-boot-starter-webflux явно не указана версия и подтягивается старая исходя как-то из немного устаревшего spring-boot-starter-parent.
Явно указал в pom-е последнюю версию spring-boot-starter-webflux - не помогло, spring-webflux и reactor-netty в зависимостях оставались устаревшими.

Артифакты spring-web, spring-webflux и reactor-netty нигде в проекте ни в одном pom-е не заданы.
Задал их явно с указанием последних версий и проект после этого успешно скомпилировался.

На инфраструктуре компании сервис еще раз прогнался на тесты, собрался образ Docker и начался процесс установки на сервер.
И тут опять ошибка про отсутствие используемых функций в двух классах, ранее упомянутых.
Я не понимаю как Maven подтягивает старую версию артифактов когда задана уже конкретная версия в pom.xml
Задал версии в pom-е в скобках (н-р. [0.0.7] вместо 0.0.7) - тоже не помогло.

Может быть кто-то уже сталкивался с подобным или знает как иначе можно заставить Maven тянуть последнии/указанные версии артифактов?
Спасибо

Answer 1

[BorLaze]

Попробуй исключить обновленные модули из спринговых зависимостей.
Примерно так:

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.tomcat</groupId>
                    <artifactId>tomcat-jdbc</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.hibernate</groupId>
                    <artifactId>hibernate-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.hibernate</groupId>
                    <artifactId>hibernate-entitymanager</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Comments

[Мира Рузвельт]

Никак руки не доходили отписаться чем закончилась история.

В первую очередь спасибо за exclusions, не знал о нем ранее.
Вариант, к сожалению, не подошел из-за огромного кол-ва зависимостей в каждом pom.xml-е модуля в сервисе.
Пришлось бы почти из каждой зависимости исключать мои зависимости что сказалось бы на читабельности.

Сам позже нарыл про dependencyManagement.
Если зависимость подтягивается из любого места сервиса и при этом указана в нем - подтянется версия из него.
Добавил его в родительский pom.xml, в нем указал свои зависимости с нужными версиями, а в дочернем pom.xml просто добавил свои зависимости без версии и проблема решилась, подтягивались ожидаемые мною версии зависимостей.

Сюрприз ждал при удаленном деплое (ci/cd) - там каким-то образом подтягивались старые версии. Возможно запуск сервиса происходил отличным от запуска в IDEA способом и подтягивание старых версий обгоняло подтягивание новых версий...разобраться в этом уже не удалось.

Более опытные коллеги-джависты поисследовали проблему и пришли к компромиссу - оставили выбор версии за Spring-ом (то есть забили на подтягивание старых версий зависимостей) и где-то в коде нашли альтернативы еще не существующим в сторонних библиотеках классам/методам, где-то выпили новый функционал в виду его незначительности.