I have some test code in Intellij Idea 2018 community edition, which has multiple pom files. When I run any testng annotated test, I get an error which says "no tests were found". It looks like the problem is due to this part of the exception stack trace:
java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonMerge
I googled for a solution and found this - https://github.com/FasterXML/jackson-annotations/issues/119 and this https://stackoverflow.com/a/46406070. It looks like this issue is caused when we don't have the same version of these jars in the project.
1) jackson-core (2.8.8)
2) jackson-databind (2.9.2)
3) jackson-annotations (2.8.5)
As you can see, I don't have the same version for all the jars. I looked at all the poms in my project and did not find any place where all these dependencies are added. I was hoping to simply set the version number there. Should I simply add all dependencies in my parent pom file or do something else ?
How do I resolve this issue without harming the project ? How do I find out why these jars are not of the same version ?
You most likely have different versions imported through different dependencies as sub-dependencies.
You can get maven to show you the so-called "effective pom" which will give you the full dependency tree, from which you can then see where what's included.
Some IDEs (like IntelliJ) have an option to show this graphically, which makes finding conflicts like this a lot easier.
Exclude lower versions, and if required explicitly add dependencies to newer versions.
The keyword you are looking for is "Dependency Exclusion". Maven includes transitive dependencies automatically. You first need to identify where the dependencies are coming from.
You can redirect the output to a file and analyze it in detail by searching for "jackson" in the tree.txt file generated as follows:
mvn dependency:tree -Dverbose > tree.txt
Next step would be find out whether you can upgrade some of your libraries so that they automatically use the right version of jackson libraries for you.
Finally, if you explicitly want to exclude transitive dependencies, you can use <exclusions> tag inside a certain <dependency> to exclude certain third party dependencies added to your classpath. See this SO question, for example.
Related
I use both Intellij IDEA (2018.3.5) & Eclipse IDEs, but I prefer Intellij. I have a maven based Java project with multiple poms. I added some dependencies to one of the pom files. I need to find out if there are any dependency conflicts which could prevent the build from running when its deployed, and then exclude them. I tried the steps given below to find conflicts which could cause problems. Are they enough or do I need to do more ?
Check if there are any compile time dependency conflicts with mvn clean install -DskipTests. Build was successful with no errors.
Check if Intellij shows no problems under File > Project Structure > Problems. There are no problems.
I also saw the dependency tree with mvn dependency:tree -Dverbose. It has a lot of "omitted for duplicate" and "omitted for conflict with" items, but the build was successful. I don't see any errors though. Does this mean that everything is okay or do I have to do something more about these conflicts ?
The best way to tell if everything is fine with your application is to have good tests.
However normally one doesn't exclude transitive dependencies from project's <dependency> libraries. Doing it can potentially break the dependency in a subtle and hard to notice way. It's usually safer to remove the whole <dependency>.
There are few scenario when one should use <exclude>:
Dealing with incompatible transitive dependencies between different libraries e.g. A requires library C-1.0 but library B requires library C-2.0 while C-1.0 and C-2.0 can't coexist on the classpath.
Having transitive dependencies already provided by system e.g. deploying to Tomcat with additional JARs in the TOMCAT_HOME/lib directory.
If you decide to exclude a dependency it's important that you check the final artifact because sometimes plugins do weird things e.g. there were versions of maven-assembly-plugin affected by a bug that resulted in different dependencies being resolved during shaded JAR creation than maven-dependency-plugin used for compilation.
I have some test code in Intellij Idea 2018 community edition, which has multiple pom files. When I run any testng annotated test, I get an error which says "no tests were found". It looks like the problem is due to this part of the exception stack trace:
java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonMerge
I googled for a solution and found this - https://github.com/FasterXML/jackson-annotations/issues/119 and this https://stackoverflow.com/a/46406070. It looks like this issue is caused when we don't have the same version of these jars in the project.
1) jackson-core (2.8.8)
2) jackson-databind (2.9.2)
3) jackson-annotations (2.8.5)
As you can see, I don't have the same version for all the jars. I looked at all the poms in my project and did not find any place where all these dependencies are added. I was hoping to simply set the version number there. Should I simply add all dependencies in my parent pom file or do something else ?
How do I resolve this issue without harming the project ? How do I find out why these jars are not of the same version ?
You most likely have different versions imported through different dependencies as sub-dependencies.
You can get maven to show you the so-called "effective pom" which will give you the full dependency tree, from which you can then see where what's included.
Some IDEs (like IntelliJ) have an option to show this graphically, which makes finding conflicts like this a lot easier.
Exclude lower versions, and if required explicitly add dependencies to newer versions.
The keyword you are looking for is "Dependency Exclusion". Maven includes transitive dependencies automatically. You first need to identify where the dependencies are coming from.
You can redirect the output to a file and analyze it in detail by searching for "jackson" in the tree.txt file generated as follows:
mvn dependency:tree -Dverbose > tree.txt
Next step would be find out whether you can upgrade some of your libraries so that they automatically use the right version of jackson libraries for you.
Finally, if you explicitly want to exclude transitive dependencies, you can use <exclusions> tag inside a certain <dependency> to exclude certain third party dependencies added to your classpath. See this SO question, for example.
I have the following dependency defined in my pom.xml
<dependency>
<groupId>runtime_shared</groupId>
<artifactId>org.boofcv</artifactId>
<version>[1.0,)</version>
</dependency>
with which I wanted to say "Take all the jars starting from version 1.0". I guess this is the correct way.
I have two versions in my local repository (.m2/repository) and I need both of these jars to have a successful compilation. However, I get an error saying that some packages do not exist. I checked the debug output and saw that maven only considers one of the jars (the last version) during the compilation, disregards the other one. And when I looked at the error message closely, I noticed that the packages it is talking about, are in the jar which is disregarded.
[DEBUG] /home/user/.m2/repository/runtime_shared/org.boofcv/1.0.2/org.boofcv-1.0.2.jar
Does anyone know why isn't version tag working?
You are referring to a syntax unique to the maven enforcer plugin.
Such syntax like [1.0,) is not valid for normal use of maven projects.
As per Jens' comment, you should specify a concrete version.
Here is the plugin documentation
I experimented with webservices and jboss4 for the last couple of days, and I stumbled over the following problem:
I included this dependency in my pom.xml:
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-jaxws</artifactId>
<version>4.2.2</version>
</dependency>
As it turned out, this caused JBoss4 to fail with the error message
java.lang.IllegalStateException: Cannot find endpoint meta data
Until I added the tiny little line
<scope>provided</scope>
to the dependency. I now understand that this problem was caused by the fact, that JBoss4 brings this library himself, and that it is the double inclusion of the same library (probably 2 different versions) that caused this. But now, when I look into the JBoss lib folder I see the following files:
commons-codec.jar
commons-httpclient.jar
commons-logging.jar
concurrent.jar
endorsed
getopt.jar
jboss-common.jar
jboss-jmx.jar
jboss-system.jar
jboss-xml-binding.jar
log4j-boot.jar
How do I know which jars correspond to which maven artifact? How do I know for any of the million files in my .m2/repository folder which groupid, artifactid and version number they belong to?
All the jar files in provided/included by Jboss are not related to maven. They are there just for the sake for jboss it self to run. Other application who wants to run in the container need to provide they own sets of library. BUT, some time, some of the library provided by JBoss is enough for the application (since they will live on the same VM), so you dont need to provide your own. You use those provided library for your development purpose, and later, when you deploy, you dont include them in your deployment.
So, there are no telling which Jar, provided by JBOSS should relate to which artifactId or groupId or version in the maven repositories, unless for some hint on their names.
For example, if you see that Jboss brings "commons-codec.jar" with it. There are no telling that the jar comes from which artifactId or groupId or version in Maven. You may guess that "commons-codec" should be a name of some artifact. Sites like http://mvnrepository.com/ helps you to find what related maven artifact that may relate to the jar you are investigating.
The artefact name is always ${artifactId}-${version}.${type}
in your case : jboss-jaxws-4.2.2.jar.
You're just looking for it in the bad place, the lib folder you're talking about must be the one of the unified classloader, the library you're looking for must be loaded by the server classloader i.e. it must reside in JBOSS_HOME/modules
[edit]
Ferdinand Neman is right when he says that jboss is not related to maven. Dependencies declaration in pom just allows maven to build and package your project. The runtime behavior depends on your targeted environment, the only things to ensure is that your dependencies must be resolved during classloading whether because they are packaged with your project or provided by the runtime environment.
Anyway the jar jboss-jaxws-4.2.2.jar will necessary be present on your workstation (in the local maven repository) to allow class linkage during maven compilation, as the jar is marked as provided it will not be included in the resulting build artefact.
Maybe you find useful this maven command
mvn dependency:tree -Dverbose
It shows you jar dependencies, classified by group-artifact and it also represents dependencies between them as a tree.
I have several gradle projects in my eclipse workspace. For the sake of simplicity I'm only really interested in 2 of them, let's just use A and B for this.
So the problem I'm having is that Project A has an included dependency on JBoss, which pulls in javax validation-api 1.0.0.GA, and Project B has a dependency on javax validation-api 1.1.0.Final. Since Gradle itself resolves the conflict by using the newer library first, B is happy when built by gradle. But Eclipse itself includes errors which are very distracting while editing.
The correct version of the validation-api jar ends up in B's class path but the problem is that the Gradle IDE plugin changes the project(':A') dependency to a project reference, and Eclipse seems to give the project reference precedence over the external jar. So the old jar is preferred by extension.
I tried adding { exclude module: 'validation-api' } in B's build.gradle for the dependency on A which works according to the output of 'gradle dependencies', however since Eclipse just gets as far as making it a project reference, it won't exclude the jar and the problem remains.
Also per this question I tried adding { transitive = false } and the same thing happens. I don't think even the hack posed there would work for me since the .classpath contains a single reference to the Gradle container so there's nothing to remove.
I've managed to get around this by explicitly including a reference to the correct version of the jar from my gradle cache and then moving it above the Gradle Classpath Container so that eclipse sees that version first.
My question is: Is there a better/more generic way to do this? Preferably one that I can commit to source control without breaking other people's builds or requiring them to manually modify paths or properties somewhere? There is another project with what appears to be a similar issue so something I can fix in the build.gradle file would be awesome.
Worst case scenario, I could probably switch to IntelliJ if that behaves itself better than the Eclipse-Gradle integration?
These kind of transitive dependency issues are long-standing problem with Gradle Eclipse integration (both in STS tooling and also commandline generated .classpath metadata from Gradle's Eclipse plugin. The problem is the way that Eclipse computes transitive classpaths.
Only recently we found a reasonable solution to this problem. Actually there are now two solutions, one better than the other but depending on your situation you might want to use either of them.
The first solution is a bug fix that changes the classpath order of project dependencies so that they are no longer 'preferred' over jar dependencies PR-74. To get this fix you may need to install gradle tooling from a snapshot update site because the fix went in after 3.6.3.
This solution doesn't fix the real problem (you still have the 'wrong' stuff on the classpath) but just makes it less likely to cause real problem in your projects.
The second solution is to enable use of the 'Custom Tooling API model' PR-55 introduced in STS 3.6.3. This is a bit experimental and only works for recent version of Gradle, at least 1.12 but probably better to use 2.x. It also only works for projects that have 'Dependency management' enabled (if not enabled you are using the .classpath generated by Gradle's eclipse plugin which has the same 'broken' classpath issues as the STS tooling).
The 'custom tooling model' is really the better solution in principle as it fixes the way gradle classpath get mapped to eclipse projects so that project dependencies are no longer exported and each project gets its own classpath considering dependencies conflict resolution.
To enable this go to "Window >> Preferences >> Gradle" and enable checkbox "Use Custom Tooling Model".