We are using Spring Integration version 2.2.0.RC2.
When running tests, the following exception is thrown:
java.lang.IncompatibleClassChangeError: org/springframework/core/type/classreading/AnnotationMetadataReadingVisitor
I understand this is because of a clash of Spring jars, likely due to the wrong version in the following maven dependency
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>3.2.2.RELEASE</version>
</dependency>
When using Spring Integration version 2.2.0.RC2, which version of spring-tests should be used? Furthermore, what is the best way to resolve these kind of Maven clashes in future - is there a listing of compatible versions of Spring jars?
Thanks
If you a do a mvn dependency:tree are there any org.springframework:spring-core libraries in there that are not at the expected levels?
Run that and make sure your spring version numbers are ALL consistent. Use dependencyManagement stanzas to ensure they're consistent.
This issue had the same symptoms.
We run a nightly build of SI against Spring 3.2.x; 3.1.3 is simply the minimum supported dep. To use a newer version of Spring, you can <exclude/> the transitive dependencies in your POM.
Related
In my work project, I use spark-submit to launch my application into a yarn cluster. I am quite new to Maven projects and pom.xml use, but the problem I seem to be having is that hadoop is using an older version of google protobuf (2.5.0) than the internal dependencies I'm importing at work (2.6.1).
The error is here:
java.lang.NoSuchMethodError:
com/google/protobuf/LazyStringList.getUnmodifiableView()Lcom/google/protobuf/LazyStringList;
(loaded from file:/usr/hdp/2.6.4.0-91/spark2/jars/protobuf-java-2.5.0.jar
by sun.misc.Launcher$AppClassLoader#8b6f2bf7)
called from class protobuf.com.mycompany.group.otherproject.api.JobProto$Query
Since I'm not quite sure how to approach dependency issues like this, and I can't change the code of the internal dependency that uses 2.6.1, I added the required protobuf version as a dependency to my project, as well:
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>2.6.1</version>
</dependency>
Unfortunately, this hasn't resolved the issue. When the internal dependency (which does import 2.6.1 on its own) tries to use its proto, the conflict occurs.
Any suggestions on how I could force the usage of the newer, correct version would be greatly appreciated.
Ultimately I found the Maven Shade Plugin to be the answer. I shaded my company's version of protobufs, deployed our service as an uber jar, and the conflict was resolved.
Spring data gemfire 1.7.0.RELEASE has compile time dependencies on version 1.7.12 of slf4j-api and jcl-over-slf4j. I have defined the below dependencies in my maven pom file, as we need slf4j 1.7.10 dependency (few other jars depend on this):
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-gemfire</artifactId>
<version>1.7.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.10</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.10</version>
<scope>runtime</scope>
</dependency>
I have an internal maven repo as the Maven central repository. Below is the behavior I see in different scenarios, based on what jars are available in the maven central:
My questions:
In scenario 1, I don't understand why the build didn't complain about missing 1.7.12 jar. How did the dependency get resolved?
In scenario 2, how's the 1.7.10 jar overriding the 1.7.12 without me specifying an exclusion for slf4j 1.7.12 in the spring data dependency?
In scenario 3, when the pom for slf4j-parent 1.7.12 is missing in Maven central, why does it complain? Since 1.7.10 jars are present, shouldn't the build run fine picking up the 1.7.10 jars (similar to scenario 1)?
The answer is based on the Maven Dependencies Mediation mechanism, specifically this statement:
You can always guarantee a version by declaring it explicitly in your project's POM
So, essentially, by explicitly declaring it as part of your dependencies, you are overriding any version on transitive dependencies, as such you don't need to add any exclusion. You declare it, you have the knowledge of the project, Maven trusts you.
So in scenario 1 and 2 Maven applied the rule above and just followed what is specified in the POM.
In scenario 1, since it didn't find any 1.7.12 version at all, it even didn't try to resolve it and trusted your POM.
In scenario 2, it resolved the dependencies tree of 1.7.12, but then based on your POM, the version 1.7.10 won.
In scenario 3 it couldn't resolve the whole dependency tree of version 1.7.12 and as such it gave an error: yes, the version from your POM would have won anyway, but since Maven had an error on getting the full dependency tree, it then failed its execution.
This is a special case though, and final confirmation could only be given looking at the concerned code of the Maven version you are using.
Update
What I would suggest to try in the three scenarios to have a bit more of details, is to run from the console:
mvn dependency:resolve -Dsort=true -X
Thanks to the debug flag, it will provide a list of included and excluded dependencies during the Dependency Mediation process.
As a complement, running:
mvn dependency:tree
Would give you the full dependency graph, showing what was actually taken from the POM and what came through transitive dependencies. That might give you further info. For further details, I would suggest to have a look at the Maven Dependency Plugin goals.
i am new to spring framework. When i try to download required jar files for spring, then there is 2 options for same classes-
org.springframework.xyz-2.5.6.A.jar and spring-xyz-2.5.6.RELEASE.jar.
I want to know what is the difference and which is recommended to use?
thanks.
The org.springframework.xyz version is the artifact ID used by SpringSource in their Enterprise Bundle Repository, a self-contained set of OSGi-compliant JARs for both Spring and non-Spring artifacts. The spring-xyz version is the standard non-OSGi version available on Maven Central.
If you're using OSGi then use the EBR JARs, if you're not then use the standard ones.
The current Maven dependency for spring-context is
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.2.4.RELEASE</version>
</dependency>
The resulting JAR is spring-context-3.2.4.RELEASE.jar.
So the second name looks OK to me.
I have a maven project in eclipse with m2e plugin. Dependency hierarchy is showing it is omitting spring 3.2.3 in place of 3.0.0.RELEASE as shown below. How to do it otherwise? Should it not omit the older version and keep the latest?
Maven works on the principle of nearest wins strategy while resolving the dependency conflicts , that means whichever version it finds nearer in the tree , it will take that version and ignore the other versions.
In your case when you can run -
mvn dependency:tree -Dverbose -Dincludes=spring-aop
You will notice that in the tree hierarchy version 3.0.0 is coming earlier in comparison to version 3.2.3 , so that's why it is taking version 3.0.0 version for resolving the dependency.
Solution : As a recommended solution to these types of problem is have a proper dependency management in your parent pom.xml file. Like in your case you can have something lik e this :
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>3.2.3</version>
</dependency>
<dependencies>
</dependencyManagement>
Now no matter what whenever Maven try to resolve the version for spring-aop , it will always consult the dependency management and will use the version defined under dependencyManagement.
For more you can refer here on my blog: how maven resolves dependency conflicts
I am updating from Spring 3.0.5 to Spring 3.1.2 and while updating spring security core is also updated to 3.1.2 which in turn has dependency on aspectjrt (mentioned in its pom) but after updating to 3.1.2 if i generate dependency tree using
dependency:tree
it does not list aspectjrt in the tree but if i generate the same tree using version 3.0.5 aspectjrt is listed in the dependency tree.
Also, as previously mentioned I have already verified that aspectjrt dependency exists in both poms (version 3.0.5 & 3.1.2).
Since aspectjrt in not listed as a dependency my code is not compiled as it requires classes from aspectjrt.
If i explicitly inlude aspectjrt dependency in my pom my code compiles successfully.
Does anybody have any idea why this issue is occuring after updating to 3.1.2? Why aspectjrt is not inluded as a dependency after updating to 3.1.2
Is there any workaround for this or i will have to work by including aspectjrt as explict dependency in my pom.
AspectJ is declared as optional dependency in spring POM. Which means that AspectJ is required to build Spring JAR but is not required to build your project when you include Spring as dependency. If you need AspectJ functionality, include it in your POM.
I have solved the issue. This is the expected behavior as spring security core 3.0.5 aspectjrt is not optional but in spring securoty core 3.1.2 they have marked aspectjrt as optional.
So,if you are using some piece of aspectjrt in your code you will have to include aspectjrt dependency in your pom.
Hope that helps.