I'm having some problems with conflicting versions of some jars. I have a dependency on a library group-a:artifact-a:0.0.1 that has a dependency on group-b:artifact-b:0.0.1, but I don't want that group-b:artifact-b:0.0.1 to be included given that I know that at runtime there will be group-b:artifact-b:0.0.2.
How do I have to write the pom.xml file?
Is this one of the following correct? And what's the difference between these?
Solution 1:
Exclude group-b:artifact-b from group-a:artifact-a:0.0.1:
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>0.0.1</version>
<exclusions>
<exclusion>
<groupId>group-b</groupId>
<artifactId>artifact-b</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
Solution 2:
Add group-b:artifact-b dependency as provided:
<dependencies>
<dependency>
<groupId>group-b</groupId>
<artifactId>artifact-b</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>0.0.1</version>
</dependency>
</dependencies>
Solution 3:
Add group-b:artifact-b dependency as runtime:
<dependencies>
<dependency>
<groupId>group-b</groupId>
<artifactId>artifact-b</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>0.0.1</version>
</dependency>
</dependencies>
Solution 4:
Add group-b:artifact-b dependency as provided or runtime and exclude it from group-a:artifact-a:0.0.1.
UPDATE:
Sorry for not being explicit, but yes #Tunaki's assumption is correct, the dependency group-b:artifact-b:0.0.2 is not required at compile time.
Option 5: Just declare the version explicitly in your POM.
Maven will overwrite the transitive dependencies if you explicitly declare them in the pom. You don't need to do any mucking about with provided or runtime scope.
According to the docs (emphasis mine):
Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.
So your pom should just be:
<dependencies>
<dependency>
<groupId>group-b</groupId>
<artifactId>artifact-b</artifactId>
<version>0.0.2</version>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>0.0.1</version>
</dependency>
</dependencies>
You should use solution 4. Let's go through each solution:
Solution 1
This is using the exclusions principle of Maven. Maven resolves dependencies transitively. But when you do not want a specific transitive dependency to be included in your classpath, you can exclude it using this mechanism.
The excluded dependency will not be used at compile-time or run-time.
But this is not what you want, since you know that your project requires group-b:artifact-b at run-time. In this scenario, the pom.xml does not declare it.
Solution 2
You are using the provided scope. provided in Maven means that this dependency is required at compile-time but should not be included in the final artifact. Typically, this dependency will be provided at run-time by a container, such as a web server.
As such, Maven will override the transitive dependency group-b:artifact-b:0.0.1 of group-a:artifact-a. In the final dependency tree, group-b:artifact-b:0.0.2 will be resolved as a provided dependency and will not be included in the final artifact (for example, if building a war, this library will not end up in WEB-INF/lib).
Solution 3
This time, you are using the runtime scope. This is much like Solution 2.
The difference is that in the final dependency tree, group-b:artifact-b:0.0.2 will be resolved as a run-time dependency and will be included in the final artifact (for example, if building a war, this library will end up in WEB-INF/lib).
Solution 4
This is the same as solution 2 and 3. The difference is that Maven will not override the dependency since you are explicitely excluding it from the list of transitive dependencies of artifact-a. But the result will be the same.
What is the correct solution?
This really depends on how your dependency will be present at run-rime. If it provided by a container, you should use Solution 4 with the provided scope. If not, you should use Solution 4 with the runtime scope.
I am suggesting this solution because:
You are explicitely excluding the unwanted dependency from artifact-a transitive dependency: this makes it more clear that that specific dependency should not be used in the project.
You are explicitely including the wanted dependency in the right scope and the right version. Again, this makes the pom.xml easier to read and to understand.
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>0.0.1</version>
<exclusions>
<exclusion>
<groupId>group-b</groupId>
<artifactId>artifact-b</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>group-b</groupId>
<artifactId>artifact-b</artifactId>
<version>0.0.2</version>
<scope>provided</scope> <!-- or runtime, depending on your specific case -->
</dependency>
</dependencies>
Related
I have a project which uses the latest version of Hibernate (let's say v2.0). I'm using it all around the project. But my project also uses some dependency (let's say MySQL Connector), which uses Hibernate (let's say v1.0). So in my pom.xml I would have something like:
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>Hibernate</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.mysql</groupId>
<artifactId>MySQLConnector</artifactId>
<version>3.7</version>
</dependency>
</dependencies>
In the end, when I compile my project, the version of Hibernate downloaded and used is v1.0 because MySQLConnector needs this one. Is there a way to specify some version of a dependency that will be used only by one of my dependencies and the rest of the code to use another version? So something like:
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>Hibernate</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.mysql</groupId>
<artifactId>MySQLConnector</artifactId>
<version>3.7</version>
<somemagicaltag>
<groupId>org.hibernate</groupId>
<artifactId>Hibernate</artifactId>
<version>1.0</version>
</somemagicaltag>
</dependency>
</dependencies>
Thus allowing MySQLConnector to use the older version of Hibernate if it likes it, but the rest of my code to use the newer, more updated version of Hibernate?
Is there a way to specify some version of a dependency that will be
used only by one of my dependencies and the rest of the code to use
another version?
No. There can be only one. So in your case either 1.0 or 2.0 (usually using newer version makes more sense). Which version is used depends on the order of dependencies in pom.xml which use such transitive dependency: Why order of Maven dependencies matter?
You can also define which version will be used by specifying such dependency (this overrides transitive dependency version) or by defining such dependency either in dependencyManagement tag: Differences between dependencyManagement and dependencies in Maven or by using BOM mechanism: Maven BOM [Bill Of Materials] Dependency
In all "normal" cases, the dependency that you declare wins against the ones that come transitively. So I would assume that in your setup, you get version 2 of hibernate (and nothing else). You can find out by calling mvn dependency:list.
You cannot load the same class twice in different versions, so normally, you cannot have two versions of hibernate in the same project. There are approaches around this (using the Maven shade plugin), but this should be the exception. Try to make your own code and your dependencies work with the same version of hibernate.
You can skip downloading that default artifact which is getting downloaded by Maven.
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>Hibernate</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.mysql</groupId>
<artifactId>MySQLConnector</artifactId>
<version>3.7</version>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>org.hibernate</groupId>
<artifactId>Hibernate</artifact>
</exclusion>
</exclusions>
</dependency>
</dependencies>
My situation is a bit strange:
Dependency with artifact id: yyy in the pom (see below) has dependency:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>2.5</version>
</dependency>
So the problem is I need to use the 3.1.0 version in the current module because it has extra functionality:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
I have tried the exclusions tag and dependencymanagement tag explained in the example on the page: Maven: how to override the dependency added by a library
It does not work. I have also read and tried the 3 examples in this article: https://spring.io/blog/2016/04/13/overriding-dependency-versions-with-spring-boot
It also did not work. So what I did was to re-order my pom dependencies so that the 3.1.0 goes before the one with artifact yyy and I was happy it worked I built successfully a clean install. My happiness was short lived because after a clean install the pom re-ordered itself and the 3.1.0 was automatically re-ordered back below the yyy. Which means the next build will use 2.5 again and fail.
My pom structure snippet is as below:
<dependencies>
<dependency>
<groupId>xxxx.xxx.xxxx</groupId>
<artifactId>yyy</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
<dependencies>
My happiness was short lived because after a clean install the pom
re-ordered itself and the 3.1.0 was automatically re-ordered back
below the yyy. Which means the next build will use 2.5 again and fail.
Note that the javax.servlet:javax.servlet-api has to be included in a WAR but only in a standalone JAR that includes and bootstraps a servlet container.
If you build a standard WAR you have to use the dependency provided by the server. So the dependency should be declared with the provided scope.
I have tried the exclusions tag and dependencymanagement tag explained
in the example on the page: Maven: how to override the dependency
added by a library
dependencyManagement will be helpless here as the issue is related to a dependency you include outside the dependencyManagement element.
But using the exclusions option in the dependency declaration is the right way. It should exclude the 2.5 version of the javax.servlet-api artifact if used in this way :
<dependencies>
<dependency>
<groupId>xxxx.xxx.xxxx</groupId>
<artifactId>yyy</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<artifactId>javax.servlet</artifactId>
<groupId>javax.servlet-api</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
</dependencies>
If the problem persists it means that the dependency is probably pulled by another dependency.
Some hints that generally help to discover that :
check that you don't use WAR overlay feature. But not likely here as you retrieve only 1 version of the dependency
use mvn dependency:tree on the WAR project to inspect all pulled dependencies.
To ease the readable you can also filter in this way :
mvn dependency:tree -Dincludes=javax.javax.servlet-api
The solution below has ignored the version 2.5 and so it is working. However i don't know what it means. Does it remove other dependencies? Please interpret what the asterix in groupId and artifactId mean in simple english. I want to know the risks because i am using a multi module system where there to many nested dependencies in other dependencies. I will continue to research as of now but if anyone can explain please do. Thanks
<dependencies>
<dependency>
<groupId>xxxx.xxx.xxxx</groupId>
<artifactId>yyy</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId> // this works or
<groupId>*</groupId> // this works
<artifactId>*</artifactId> // this part was a mandatory *
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
</dependencies>
I want to use the last version of the powermock library (1.6.5) through Maven. But My package cannot be compiled, since Maven finds dependency Convergence error. Below you can see that there are 2 different versions of org.objenesis:objenesis library in the same dependency:
Dependency convergence error for org.objenesis:objenesis:2.1 paths to
dependency are:
+-mypackage:v1-SNAPSHOT
+-org.powermock:powermock-api-mockito:1.6.5
+-org.mockito:mockito-core:1.10.19
+-org.objenesis:objenesis:2.1
and
+-mypackage:v1-SNAPSHOT
+-org.powermock:powermock-api-mockito:1.6.5
+-org.powermock:powermock-api-mockito-common:1.6.5
+-org.powermock:powermock-api-support:1.6.5
+-org.powermock:powermock-reflect:1.6.5
+-org.objenesis:objenesis:2.2
I tried to make an exclusion, but I cannot exclude only one version, I need to exclude all of them, which does not pass me, as I think.
Did you have the same problem? What can I do?
There two different version of objenesis, because two different libraries depends on two different version ofobjenesis`: PowerMock and Mockito. You have two options to resolve the issue:
Exclude org.objenesis:objenesis from PowerMock dependencies and add it manually to your pom.
Exclude mockito-core from PowerMock dependencies and add it as separated decency to your pom with excluding objenesis.
I followed the answer from Arthur, but only made an exclusion for objenesis to the powermock-module-junit dependency. After that the enforcer plugins was happy.
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4</artifactId>
<version>1.7.0</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.objenesis</groupId>
<artifactId>objenesis</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-api-mockito2</artifactId>
<version>1.7.0</version>
<scope>test</scope>
</dependency>
I'm following this guide:
https://github.com/maxmind/GeoIP2-java
It says:
We recommend installing this package with Maven. To do this, add the dependency to your pom.xml:
<dependency>
<groupId>com.maxmind.geoip2</groupId>
<artifactId>geoip2</artifactId>
<version>2.2.0</version>
</dependency>
There is also pom.xml file in the Git repository of GeoIP2 which is much longer - what is the difference between them?
Cited from the official homepage:
Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
Think of the pom.xml as the heart of Maven. In the file you can specify dependencies (most typically jar files), and other information, such as how the project should be built. Without digging to deep into this, one of Maven's strengths is that it manages the dependencies of projects.
To answer your concrete question, GeoIP2 manages its dependencies using Maven. This section of its pom.xml defines them:
<dependencies>
<dependency>
<groupId>com.maxmind.db</groupId>
<artifactId>maxmind-db</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.google.http-client</groupId>
<artifactId>google-http-client</artifactId>
<version>1.20.0</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.5.3</version>
</dependency>
</dependencies>
By using Maven in your own project, you will only need to add the one dependency to GeoIP2. Maven will then search for the dependency in a repository, typically the Maven Central Repository if Maven isn't configured to use another. It will also automatically download all other needed dependencies (transitive dependencies), in this case it would be the dependencies listed above, plus any other dependencies those in turn depend on, and so on.
So, a short recap: Without a dependency management tool like Maven, you would need to manually make sure you have all the correct dependencies on the classpath. Maven fixes this for you.
I have a project foo-instrumented that depends on foo.
This project actually instruments foo with additional code, and replaces it. That is, foo is a compile-time dependency of foo-instrumented but it is definitely not a runtime dependency (foo-instrumented replaces foo), and it should not be propagated to children (that is, projects depending on foo-instrumented should not end up depending on foo).
Is there an appropriate maven scope for that kind of dependency, or another solution?
Edit: I am not being clear enough with my request: although foo should not end up in the children project dependencies, foo's dependencies should (e.g. if foo depends on log4j, then a project that depends on foo-instrumented should have log4j as part of its dependencies), which seems to rule out the provided scope.
Thanks!
Edit: Okay, I need to have a little rant here: DID ANY REAL, ACTUAL HUMAN BEING ACTUALLY UNDERSTAND THE MAVEN DOCS? I had a look at a few pages and guess what: no explanations, no illustrations, JUST TONS OF XML VOMIT. XML VOMIT IS NOT DOCUMENTATION, PEOPLE!
You should use the import scope. In your foo-instrumented project:
<dependencies>
<dependency>
<groupId>bar</groupId>
<artifactId>foo</artifactId>
<type>pom</type>
<scope>import</scope>
<dependency>
<dependencies>
This will pull the dependencies of foo into foo-instrumented without also including foo.
You cannot exclude a dependency, but still include it's dependencies.
However, you can define an exclusion for your non-instrumented dependency and add the dependencies over to your other module (again). When you define the dependency to foo-instrumented, do:
<dependencies>
<dependency>
<groupId>bar</groupId>
<artifactId>foo-instrumented</artifactId>
<exclusions>
<exclusion>
<groupId>bar</groupId>
<!-- Exclude the non-instrumented dependency: -->
<artifactId>foo</artifactId>
</exclusion>
</exclusions>
<dependency>
<!-- Add the dependencies you need for foo to work here -->
<dependencies>