Я использую стартер 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 и регулярно пытаться сушить проект до этой новой версии, но не обязательно поставлять это обновление для производства. Это позволяет оценить риск обновления и оценить объем работы, которая должна идти на это. Избегание обновлений в основном просто делает их более болезненными, но да, иногда их нельзя сделать сразу из-за политических причин или из-за того, что обновление сталкивается с проблемами в более новых версиях.