I'm using the Spring IO 1.0.1 BOM to manage my dependencies for my project. I've imported it in my super-pom's dependency management section like this -
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.spring.platform</groupId>
<artifactId>platform-bom</artifactId>
<version>1.0.1.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
...
Now, in a submodule POM of my project, I've declared these dependencies
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
</dependency>
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.0-api</artifactId>
</dependency>
And my final packaged war includes both hibernate-jpa-2.0 and hibernate-jpa-2.1. Since the entity manager depends on 2.1 and the api is 2.0. These are causing conflicts within my deployed app.
I cannot find a declaration of 2.1 in the platform bom so I'm confused about how to proceed. The documentation lists both of these as libraries provided by the platform, but the BOM doesn't provide any resolution between their conflicting versions. What is the recommended approach? Should I manually exclude 2.0 and explicitly declare 2.1 even if its not in the parent BOM? Should I force hibernate-entitymanager to use the 2.0 APIs?
I was hoping that the IO platform BOM would help me with these kinds of collisions.
Related
I am using below Red Hat Fuse BOM for my camel application to get the camel dependencies for my project. It returns camel dependencies version 2.23.x
<dependencyManagement>
<dependency>
<groupId>org.jboss.redhat-fuse</groupId>
<artifactId>fuse-springboot-bom</artifactId>
<version>7.7.0.fuse-sb2-770010-redhat-00001</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencyManagement>
My Maven is set to get the dependency through JFrog, which blocks camel-spring-2.23.x version due to some vulnerability found in this version of jar as per our client security policy. My question is, Will it be correct to specify the camel-spring dependency in pom.xml as below to download 2.25.x version and let the other camel lib dependencies as 2.23.x ? Is it going to cause any issue in amy camel application due to different camel library versions?
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring</artifactId>
<version>2.25.2</version>
</dependency>
Which is the best way to determine the versions for my Spring modules and other libraries in a Spring Boot project?
Versions for Spring Modules
Versions for Third Party libraries
There are a lot of question when you search for "Compatible versions in Spring".
But all these questions are regarding specific libraries.
I would like to have general rules of how to determine compatible versions for my project.
You may checkout my post on this A comprehensive list of dependencies managed by latest Spring-Boot 2.3.2.RELEASE (as a custom parent)
That's is just a reference for how it should be, but you may discard the version in as they will be managed indirectly by spring itself.
Ok so, this is something almost every spring developer stumble upon. Let me try to explain this how was I able to resolve all the managed and third party libraries.
Let's suppose you want to build spring-boot microservices with a centralized configuration server.
So we can take it as following modules:
A company project starter: acts as a parent, managing the dependency
A config-server
A config-client
and let's suppose you chose spring-boot 2.3.2 version, which I used and find more stable. You would expect all the managed ones are using this spring-boot 2.3.2 version directly or indirectly.
I would highly recommend using https://mvnrepository.com
artifact: my_company-boot-starter-parent
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.2.RELEASE</version>
</parent>
<groupId>com.my_company</groupId>
<artifactId>my_company-boot-starter-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>my_company starter-parent</name>
<dependencyManagement>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- ... -->
<!-- ... -->
<!-- other dependencies -->
<!-- ... -->
<!-- ... -->
</dependencyManagement>
If you got to Spring Boot Starter Parent ยป 2.3.2.RELEASE, under Managed Dependencies you can see the comprehensive list of all the dependencies with default version that would be referenced implicitly with boot version 2.3.2, see column Version.
The Updates column indicate that these managed dependencies are having their newest updates as this, but you are not required to override the dependency version of managed ones. If you intent to use more recent version, you have to chose more recent version of spring-boot-starter-parent. So let the spring download all the managed one itself.
With spring-boot-starter-parent 2.3.2 , they do not mention which spring-cloud-dependencies verion you should use, and this is where we get stuck and we need to figure it out.
Let us got to spring-cloud-dependencies . Hee you can see numerous version but which one to chose, it's like verifying which latest version uses spring-boot 2.3.2 indirectly.
You need to follow the managed dependency and go along with it until you find your parent version.
For example If you go for :
Hoxton.SR6
Spring Cloud Dependencies(Hoxton.SR6) -> Spring Cloud Config Dependencies( 2.2.3.RELEASE) -> Spring Cloud Starter Config(2.2.3.RELEASE) -> Spring Cloud Starter(2.2.3.RELEASE) -> Spring Boot Starter(2.3.0.RELEASE)
Here you can see, we end up using Spring Boot Starter(2.3.0.RELEASE) which is not what we expected it to be.
Hoxton.SR7
Spring Cloud Dependencies(Hoxton.SR7) -> Spring Cloud Config Dependencies(2.2.4.RELEASE) -> Spring Cloud Starter Config(2.2.4.RELEASE) -> Spring Cloud Starter(2.2.4.RELEASE) -> Spring Boot Starter(2.3.2.RELEASE)
Here we end up using same boot version 2.3.2. So in your parent pom.xml, you can set the spring cloud version as :
<properties>
<java.version>15</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<lombok.version>1.18.20</lombok.version>
<spring-cloud.version>Hoxton.SR7</spring-cloud.version>
</properties>
And in child poms (jars), you can just use the dependencies justby mentioning the group and artifact, skipping the version.
sample:
<parent>
<groupId>com.my_company</groupId>
<artifactId>my_company-boot-starter-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<groupId>com.google.googlejavaformat</groupId>
<artifactId>google-java-format</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
</dependency>
</dependencies>
See, we have not provided the any version here, so spring-cloud-config-server version would be auto managed and it would be 2.2.4.RELEASE which again uses spring-boot-starter-web and spring-boot-starter both of 2.3.2 version.
Third party libraries
This is somewhat based on language version. You might want to use the latest third-party libs which is most recent till your language version supports it.
Like lombok: 1.18.20
Hope this might have helped you and others and provides an approach towards version compatibility.
Tips: Never forget to check the Managed Dependency Coordinates in Aappendix of all the spring boot release page as they keep their managed dependencies & version there. Like this one Appendix F: Dependency versions
1. Use Spring Initializr
Select all Spring modules you need in spring initializr and generate your code: https://start.spring.io/
You do not need to use the full generated code. But you should copy the library versions out of the generated pom.xml.
2. Watch out for dependency pom.xml
If available, import dependency pom.xml in your dependencyManagement.
Use the versions provided by these dependency poms.
E.g.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Spring Dependency Version Documentation
You can also check the Spring Dependency Version Documentation. But I prefer the initilizr, because it's easier to handle.
Let's say I am creating a new project, maven based, and I want to use spring 4.2.3.RELEASE.
I also want to use spring-test and spring security and X, Y and Z.
How can I know for sure what exact versions to add in maven to avoid conflicts?
Thanks
later edit:
can this help me?
Maven "Bill Of Materials" Dependency
It is possible to accidentally mix different versions of Spring JARs when using Maven. For example, you may find that a third-party library, or another Spring project, pulls in a transitive dependency to an older release. If you forget to explicitly declare a direct dependency yourself, all sorts of unexpected issues can arise.
To overcome such problems Maven supports the concept of a "bill of materials" (BOM) dependency. You can import the spring-framework-bom in your dependencyManagement section to ensure that all spring dependencies (both direct and transitive) are at the same version.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.2.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
An added benefit of using the BOM is that you no longer need to specify the <version> attribute when depending on Spring Framework artifacts:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</dependency>
<dependencies>
You are right, the BOM is one of the most powerfull ways to fight (even maven based) dependency hell.
Here is the relevant portion of pom.xml
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jackson-provider</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-all-5.0</artifactId>
<scope>provided</scope>
</dependency>
Why is the scope of resteasy compile (which is default, when none is provided) but that of javax.servlet is provided. I am deploying this on Jboss which ships with resteasy. so shouldn't the scope of resteasy be provided as well?
and btw, I do not see any version mentioned. so what is the default version that gets picked up?
If you are using jboss 7, resteasy-jackson-provider is included, so it would be correct to use a provided scope.
I guess default version is being picked up from a bom declared in the dependencyManagement section of your pom, could that be right?
For older jboss versions, resteasy is not included, so you will have to add the jars to your WEB-INF/lib directory.
Necessary jars can be obtained using maven (compile scope) or check out this link http://www.mastertheboss.com/jboss-frameworks/resteasy/resteasy-tutorial
The RESTEasy API and runtime is provided by newer versions of JBoss. Usually you import a Java EE-spec pom in the dependencyManagaement section and add the needed APIs in the dependency section, e.g for JBoss AS7:
<dependencyManagement>
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>3.0.2.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.spec.javax.ws.rs</groupId>
<artifactId>jboss-jaxrs-api_1.1_spec</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
The runtime will use the JSON-Provider which is found on the classpath. So it makes sense to add them with scope compile to your project. If you want to use Jettison you'd add following to your pom:
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jettison-provider</artifactId>
</dependency>
If you don't add one your application server may provide a default one. JBoss AS7 / Wildfly for instance will use resteasy-jackson-provider if you don't add a provider to the classpath.
JBoss 5 does not provide the JAX-RS libs as far as I know so there it makes sense to add the resteasy-jackson-provider with scope compile.
The thing is I am using Hibernate 4.3 in my web application which causes the following artifact to be included into WAR:
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.1-api</artifactId>
<version>1.0.0.Final</version>
As it follows from the dependency hierarchy this artifact is required by the Hibernate-core:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>${hibernate-core.version}</version>
</dependency>
I manually included it in my POM with Provided scope and it was then excluded from the WAR assembly.
I am questioning how to exclude all container provided APIs from the build?
Apparently, solution which is not container-specific would be the best though at least Glassfish hack is needed.
You need to set a scope for such things like:
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.1-api</artifactId>
<version>1.0.0.Final</version>
<scope>provided</scope>
</dependency>
If you are really sure that hibernate core does not need it (I'm not sure about it) you need to do an exclusion.
Furthermore i have my doubts cause in the above artifact there a some Exceptions defined so you shouldn't exclude them. The question is in which container do you use it? Does this container already provide JPA ?