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>
Related
The container 'Maven Dependencies' references non existing library 'C:\.m2\repository\com\portal\pcm\12.0.3\pcm-12.0.3.jar'
If i check the folder there are files that have the same name as the jar but end on jar.lastUpdated.
I tried maven clean and maven update which did not work. I delete the *.jar.lastUpdated in m2, but did not work too.
The line in my pom.xml is:
Missing artifact com.portal:pcm:jar:12.0.3
Missing artifact com.portal:pcmext:jar:12.0.3
Missing artifact com.portal:pcmext:jar:12.0.3
This block is the one with the marker where it states the artifact is missing.
<dependency>
<groupId>com.portal</groupId>
<artifactId>pcm</artifactId>
<version>12.0.3</version>
</dependency>
<dependency>
<groupId>com.portal</groupId>
<artifactId>pcmext</artifactId>
<version>12.0.3</version>
</dependency>
<dependency>
<groupId>com.portal</groupId>
<artifactId>pfc</artifactId>
<version>12.0.3</version>
</dependency>
I tried to use a version suggested by mvnrepository.com/artifact/com.portal.pcm/pcm/7.5, but didnt work too.
<dependency>
<groupId>com.portal.pcm</groupId>
<artifactId>pcm</artifactId>
<version>7.5</version>
</dependency>
<dependency>
<groupId>com.portal.pcm</groupId>
<artifactId>pcmext</artifactId>
<version>7.5</version>
</dependency>
<dependency>
<groupId>com.portal.pcm</groupId>
<artifactId>pfc</artifactId>
<version>7.5</version>
</dependency>
i guess dependency configuration is incorrect, but which is correct?
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>
What Google Maven dependency could fix this error:
java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;J)V
at com.google.cloud.storage.spi.v1.HttpStorageRpc.read(HttpStorageRpc.java:487)
at com.google.cloud.storage.BlobReadChannel$1.call(BlobReadChannel.java:127)
at com.google.cloud.storage.BlobReadChannel$1.call(BlobReadChannel.java:124)
at com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:94)
at com.google.cloud.RetryHelper.runWithRetries(RetryHelper.java:54)
at com.google.cloud.storage.BlobReadChannel.read(BlobReadChannel.java:124)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
Code:
Blob blob = storage.get(blobId);
if(blob.exists()) {
return true;
}
Your Google guava version is either too old (< 20.0) or mismatched (multiple jars versions). Make sure you don't have several versions in your dependency tree.
Use
mvn dependency:tree | less
to look for the guava versions.
Please add following dependencies to your project's POM:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>23.6-jre</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpcore</artifactId>
<version>4.4.8</version>
</dependency>
In my case, I happened to include both
<dependency>
<groupId>com.google.collections</groupId>
<artifactId>google-collections</artifactId>
<version>1.0</version>
</dependency>
and
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>28.0-jre</version>
</dependency>
As it turns out, I cannot use both of these libraries. Removing google-collections fixed the issue for me.
Try inserting a dependency containing a newer version of guava at the top of your dependencies in your pom.xml containing your project.
E.g.
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>24.1.1-jre</version>
</dependency>
For anybody encountering anything like this, i had the following pom:
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
<version>3.2.1</version>
</dependency>
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20190722</version>
</dependency>
<dependency>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.2</version>
</dependency>
And commenting out the maven-shade plugin fixed it for me...
I had the same issue in my Java/Kotlin application. When the app was ran via IntelliJ there were no issues. However, when the .Jar was ran the error message above was thrown.
I could not find a direct action item to take with the Guava issue defined by #Laurent Perez above so I did the following which resolved the issue with my .Jar file running:
Removed .Jar IntelliJ configurations and file from IntelliJ. Then re-added the .Jar following Step 3 from this deploy guide.
Other actions to try if the above does not work:
Rebuild project.
Invalidate IntelliJ cache and restart.
Restart computer.
It happens when you're missing guava library from your dependency. Add it using following in your pom.xml
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>24.0-jre</version>
</dependency>
Another reason could be there are multiple versions of google guava/collection library, you can't have both as mentioned by #sabbir in his comment, you ought to remove one of them.
Lastly it could be that some other dependency is dependent on the previous version of google guava/collections. Go to Dependency Hierarchy and search for google and see what all dependencies are dependent on the previous versions. In my case it was by version-maven-plugin, version 2.7
Here version-maven-plugin, version 2.7 uses google collections 1.0, and I require guava 24.0 Both can't work simuntaneously.
I excluded it in my pom.xml like this and then added a new dependency of guava
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.7</version>
<exclusions>
<exclusion>
<groupId>com.google.collections</groupId>
<artifactId>google-collections</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>24.0-jre</version>
</dependency>
Resultant: Now google-collections is gone.
I have a fairly large legacy project that I'm adding a component to. This component uses HtmlUnit. I can compile it ok with Maven but when I run it I get:
java.lang.NoSuchMethodError:
org.apache.http.conn.ssl.SSLConnectionSocketFactory.<init>
(Ljavax/net/ssl/SSLContext;[Ljava/lang/String;[Ljava/lang/String;Ljavax/net/ssl/HostnameVerifier;)
So it's missing the correct constructor. I think this is almost certainly a version conflict in httpclient but I'm not sure how to resolve it. Here's the relevant part of my pom.xml (note all the games I've been trying to play with exclusions and dependency management):
<dependencies>
<dependency>
<groupId>com.mycompany.mine</groupId>
<artifactId>my-base-project</artifactId>
<version>${project.version}</version>
<exclusions>
<exclusion>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>base-project</artifactId>
<version>${project.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.2</version>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.2</version>
</dependency>
</dependencies>
</dependencyManagement>
Any ideas?
Edit: it's been suggested that this question is a duplicate of this one, but it's not since the dependency type in this case is not war.
In order to identify conflicting dependecies, use mvn dependency:tree. I like to pipe it to a text file for ease of use:
mvn dependency:tree > tree.txt
Then, use your favorite text editor to look for multiple versions of a depedency.
Alternatively, if you are looking for a specific groupId or artifactId, use the -Dincludes flag:
mvn dependency:tree -Dincludes=<groupId>:<artifactId>:<version>:<packaging>
mvn dependency:tree -Dincludes=org.springframework <<< get all dependencies with by groupId
mvn dependency:tree -Dincludes=:spring-web <<< get all dependencies by artifactId
You might also want to add the -Dverbose flag here.
To resolve dependency conflicts, there are two ways:
1) Exclude the one you don't want
<depdency>
<groupId>some.stuff</groupId>
<artifactId>with.transitive.depdency</artifactId>
<exclusions>
<exclusion>
<groupId>something</groupId>
<artifactId>unwanted</artifactId>
<exclusion>
<exclusions>
<depdency>
With this way, you will have to exclude on every dependency that brings in a transitive one. For this reason I like the other one better.
2) Explicitly add the version you want
<dependency>
<groupId>something</groupId>
<artifactId>with.version.conflict</artifactId>
<version>what I want</version>
</dependency>
This will make sure that any transitive dependency will be swapped with this exact version. This might also lead to errors though, if some framework actually needs an older version. For using this strategy safely, your dependencies will need to be fairly close to the newest available version (or versions released at the same time).
I have a case that I have the following cyclic dependencies in maven:
JAR A version 1.1 depends on JAR B version 1.0
JAR B version 1.1 depends on JAR A version 1.0
For some reason that I don't know, Maven brings all the 4 JARs: A 1.0, A 1.1, B 1.0 and B 1.1, which results in a classpath conflict.
This really sucks. I already ask the developers of both JARs to fix this, however I can't simply sit and wait for the day that they decide to fix this.
I tried this:
<dependency>
<groupId>groupA</groupId>
<artifactId>artifactA</artifactId>
<version>1.1</version>
<type>pom</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>groupB</groupId>
<artifactId>artifactB</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>groupB</groupId>
<artifactId>artifactB</artifactId>
<version>1.1</version>
<type>pom</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>groupA</groupId>
<artifactId>artifactA</artifactId>
</exclusion>
</exclusions>
</dependency>
The result is that maven excludes all of the JARs as if none dependency were added, and the project does not compiles because there are missing classes.
So, other than just asking both JARs developers to solve this, what can I do? How can I import both the new dependencies while leaving out both the old ones?
Pragmatic solution would be to redeclare the unwanted dependencies as provided, for example:
<dependency>
<groupId>groupA</groupId>
<artifactId>artifactA</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
I'm not particularly fond of using provided in such manner, since it leaves the dependency in the compile time and could lead to unwanted compile dependencies, but I see no other way in your case ;(.