This project shows the usage of the Spring Data release train in a non-Spring-Boot project with both Maven and Gradle.
In both Maven and Gradle a couple of properties are used to define the versions of Spring Framework and Spring Data to use. For Spring Framework a plain version is used. For Spring Data we refer to a particular revision of a release train. The naming of Spring Data releases uses the following conventions:
-
${release-train}-M1→ Milestones -
…
-
${release-train}-RC1→ Release candidate -
…
-
${release-train}-RELEASE→ GA version -
${release-train}-SR1→ Services release (bugfixes) for that release train
The <dependencyManagement /> section declares dependencies to the BOMs for both Spring and Spring Data, using the import scope and pom type.
The standard <dependencies /> section can now list Spring Framework and Spring Data dependencies without declaring a version and still be sure all libraries are in matching versions.
Note, that we don’t declare a Spring Framework dependency here. The import of the Spring Framework BOM nonetheless makes sure we control the version of all transitive Spring Framework dependencies pulled in by the Spring Data modules.
Gradle does not support Maven BOMs (Bill of Materials) out of the box, so the first thing to do is important the dependency management plugin. This example is based on Java, but if you need a different language plugin (e.g. Kotlin), you can do so.
The dependencyManagement section can be used to import the Spring Framework BOM and Spring Data BOM.
The standard dependencies section can now list Spring and Spring Data dependencies without declaring a version and still
be sure all libraries are align with each other.
Note how you don’t declare a Spring Framework dependency. Nevertheless, the dependency management plugin and the Spring Framework BOM ensures you control the version of all transitive Spring Framework dependencies pulled in by Spring Data.