Как выборочно обновлять зависимость в Spring Boot? (пример: Spring Данные)

Я использую стартер Spring Data JPA Spring Boot (1.4.1). Он содержит Spring Data JPA 1.10.3. Однако мне нужно использовать аннотацию @DomainEvents, которая еще не существует в этой версии Spring. Когда я пытаюсь добавить последнюю версию Spring Data JPA, я получаю ошибки при запуске моего приложения.

Мой пример pom:

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.4.1.RELEASE</version>
        <relativePath/>
</parent>

<dependencies>
        ...
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        ...
</dependencies>

Когда я пытаюсь добавить последнюю версию Spring Data JPA, как это:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-jpa</artifactId>
            <version>1.11.6.RELEASE</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Я получаю erorrs, когда я запускаю свое приложение. Ошибки:

Caused by: java.lang.NoSuchMethodException: org.springframework.data.jpa.repository.support.JpaRepositoryFactoryBean.<init>()
  at java.lang.Class.getConstructor0(Class.java:3082) ~[na:1.8.0_121]
  at java.lang.Class.getDeclaredConstructor(Class.java:2178) ~[na:1.8.0_121]
  at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:80) ~[spring-beans-4.3.3.RELEASE.jar:4.3.3.RELEASE]
  ... 53 common frames omitted

Как я могу использовать более новую версию Spring Data JPA? Мне нужно @DomainEvents в моем приложении. Спасибо!

Ответы

Ответ 1

Существует несколько способов скин-кота здесь, чтобы все они имели разные верхние и нижние стороны:

Вариант 1: переход на более новую версию Boot

Самым безопасным способом является обновление до более поздней версии Spring Boot. Обычно мы советуем быть на последней второстепенной версии в нынешнем крупном поколении. В вашем случае 1.5 является последним несовершеннолетним, поэтому мы рекомендуем обновить его до (1.5.6). Обычно это достигается путем изменения номера версии родительского помпа, который вы используете.

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>1.5.6.RELEASE</version>
</parent>

Pros

  • Вы автоматически обновите все зависимые от Boot управляемые зависимости до их последних совместимых версий. Это рекомендуется, так как это позволит вам получить последние исправления для обновлений безопасности в зависимостях третьих лиц.

Против

  • Небольшое обновление версии может потребовать, чтобы вы немного изменили настройки своей конфигурации или API, если вы зависите от стороннего API от вашего кода приложения. Незначительные обновления версии в Boot обычно очень осторожны, когда дело доходит до того, что вы не нарушаете изменения в сторонних библиотеках, но, к сожалению, не все из них следуют семантическому управлению версиями. Однако, если у вас есть достойный набор тестов, вам должно быть легко узнать, попадете ли вы в проблемы. Он рекомендовал взглянуть на примечания к выпуску, поскольку они обычно содержат руководства по миграции.

Вариант 2: индивидуальное обновление зависимостей

Альтернатива предыдущему подходу находится в загрузочной версии, на которой вы находитесь, но выборочно обновляете зависимости сторонних разработчиков. Предпочтительный способ сделать это - проверить, какие места размещения версии существуют в spring-boot-dependencies. Затем вам нужно просто обновить свойство в своем проекте и настроить версию. Для Spring данных это будет:

<properties>
  <spring-data-releasetrain.version>Ingalls-SR6<spring-data-releasetrain.verion>
</properties>

В случае Spring Data вы обновляете весь выпускной комплект сразу, чтобы вы не сталкивались с несовместимостью между Spring модулями данных внутри, если вы просто обновляете один модуль. Это одна из основных причин, по которой это "обновление по свойствам" рекомендуется для повторного объявления зависимости в более новой версии явно (что в некоторых случаях может быть последним средством).

Pros

  • Обновление происходит гораздо более избирательно. В отличие от предыдущего подхода, вы не рискуете столкнуться с проблемами обновления несвязанных зависимостей.

Против

  • Возможно, это не сработает!. Иногда зависимости меняют некоторые внутренние API-интерфейсы, зависящие от автоматической конфигурации загрузки в младшей версии. Это может привести к тому, что автонастройка не будет работать при запуске, которую вы можете попытаться заменить, исключив автоматическую конфигурацию в явном виде и введя ручную конфигурацию.

Предлагаемые шаги

На практике я обычно делаю следующие шаги:

  • Используйте вариант 1 для обновления с минимальным воздействием. Если это будет выполнено: Готово.
  • Если это вызывает проблемы, оцените, насколько сложно заменить автоконфигурацию на ручную конфигурацию (обычно это требует немного понимания и опыта работы с Boot.Если это будет выполнено: Done.
  • Используйте параметр 2 для перехода на новую версию Boot и оцените влияние этого кода на ваш код приложения.

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

Вообще говоря, неплохо следить за выпуском Boot и регулярно пытаться сушить проект до этой новой версии, но не обязательно поставлять это обновление для производства. Это позволяет оценить риск обновления и оценить объем работы, которая должна идти на это. Избегание обновлений в основном просто делает их более болезненными, но да, иногда их нельзя сделать сразу из-за политических причин или из-за того, что обновление сталкивается с проблемами в более новых версиях.