While upgrading dependencies in a project I ran across this issue:
[INFO] --- dependency-management-maven-plugin:0.11:analyze (basepom.default) # svc-foo ---
[ERROR] Version mismatch for org.liquibase:liquibase-core:jar, managed version 4.5.0 does not match project version 4.9.1
My question is: How do I find out which package or artifact declares that liquibase-core is a managed dependency and should be at version 4.5.0?
Firstly, I know how to solve the issue (by overwriting the managed dependency in my own pom). That is not the question.
Liquibase is not declared as managed dependency in our base pom or anywhere in the direct inheritance chain.
mvn dependency:tree does not show it, as liquibase is not included as actual dependency anywhere else but in my own pom. But it is seemingly declared as managed with version 4.5.0 somewhere.
I tried all maven goals/command I could find. I read the maven docs. I searched here on stackoverflow. What did I overlook?
Related
I'm trying to make a Jenkins plugin that uses a library that requires spring-core 3.2.2 (cloudfoundry-client-lib). I simply used the mvn command to create a skeleton plugin, then added my Maven dependency to pom.xml and a few simple code lines that uses the library. I'm not getting any problem running the skeleton plugin without my dependency.
Upon compiling with "mvn package", I'm getting a test error:
WARNING: Failed to scout hudson.security.PAMSecurityRealm
java.lang.InstantiationException: java.lang.NoClassDefFoundError: org/springframework/core/env/EnvironmentCapable
Looks like this is a class that appeared in spring-core 3.1.0. So I looked at the Maven dependency tree:
[INFO] --- maven-dependency-plugin:2.3:tree (default-cli) # stackato-jenkins ---
[INFO] org.wiwiweb:cf-test-jenkins:hpi:1.0-SNAPSHOT
[INFO] \- org.cloudfoundry:cloudfoundry-client-lib:jar:1.0.2:compile
[INFO] \- org.springframework:spring-webmvc:jar:3.2.2.RELEASE:compile
[INFO] \- org.springframework:spring-core:jar:2.5.6.SEC03:compile
So Maven tells me it's using spring-core 2.5.6 because of spring-webmvc 3.2.2? This is strange because, looking online, spring-webmvc 3.2.2 depends on spring-core 3.2.2. Looking at the verbose version of the tree, looks like jenkins-core depends on spring-core 2.5.6... This makes me suspicious that the problem is from Jenkins.
Anyway, if it's just a version conflict, then overriding Maven's decision by explicitly saying I want spring-core 3.2.2 in my pom.xml should solve the problem, right?
I did this, then did not get a compile error. Problem solved!... not.
In runtime, after activating this plugin in Jenkins and running a build with this, as soon as the code runs into a line that uses the library I added, the Jenkins output tells me this:
FATAL: org.springframework.util.CollectionUtils.unmodifiableMultiValueMap(Lorg/springframework/util/MultiValueMap;)Lorg/springframework/util/MultiValueMap;
java.lang.NoSuchMethodError: org.springframework.util.CollectionUtils.unmodifiableMultiValueMap(Lorg/springframework/util/MultiValueMap;)Lorg/springframework/util/MultiValueMap;
UnmodifiableMultiValueMap() is a method that was added in spring-core 3.1, so this means Jenkins is still trying to run my plugin with the old version of spring-core, even though I explicitly said I wanted the newest one in my plugin's pom.xml!
So I'm stuck on this. I'm not even sure if it's a Maven or a Jenkins issue. I'll sum up the whole thing in two questions:
Why is Maven not compiling the plugin with a correct version of spring-core unless I explicitly tell him to? It should be able to follow dependencies without me giving it hints.
Why is Jenkins running my plugin with an older version of spring-core than the one it was compiled with, and how can I make it use the correct one?
If you're picking up dependencies from the Jenkins install rather than from your plugin the solution is actual quite easy to implement. Per the Jenkins documentation, simply add the maven-hpi-plugin to the build in the pom.xml of your Jenkins plugin and set it to load the plugin classes first:
<build>
<plugins>
<plugin>
<groupId>org.jenkins-ci.tools</groupId>
<artifactId>maven-hpi-plugin</artifactId>
<configuration>
<pluginFirstClassLoader>true</pluginFirstClassLoader>
</configuration>
</plugin>
</plugins>
</build>
Try to "shade" the CF client lib using the Maven Shade plugin, as it seems Jenkins doesn't like plugins that are using a different version of Spring than the one it uses internally itself.
Even if your own plugin doesn't use Spring directly, but the CF library does, I believe this still applies. The person that suggested shading in the jenkinsci-dev mailing list seems to be involved in Jenkins plugins development, so he might know about this more than others.
These being said, I would get the source code for cf-client-lib, I would change the pom.xml to consider shading for org.springframework package, as well (because cf-client-lib already uses shading for org.codehaus.jackson package) and I would use this "shaded" version of cf-client-lib in the Jenkins plugin.
I'v declared the dependency for com.amazonaws:aws-java-sdk:jar:1.6.8, but I'm getting jar 1.5.0.
While running mvn dependency:tree, I see the following line:
com.amazonaws:aws-java-sdk:jar:1.5.0:compile (version managed from
1.6.8)
What does it mean? How do I resolve it and actuaully get 1.6.8?
It means that in your pom.xml or in the parent of your pom.xml, their a dependencyManagement section that declares that the version of com.amazonaws:aws-java-sdk must be the 1.5.0.
Background:
I am developing Maven multi module project.
One of the module is common module needed by other all modules.
This module contain CommonClassA.java.
common module is properly compiled.
It is installed into maven local repository properly.
One of the class(Billtype.java) in other module (EmployeeBilling) refers this class(CommonClassA.java).
Maven Dependency for common module is properly specified in pom.xml of EmployeeBilling module.
Problem:
While compiling EmployeeBilling module it throws
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project EmployeeBilling: Compilation failure
[ERROR] \MyWorkspace\Biz\EmployeeBilling\src\main\java\com\employee\Billtype.java:[79,19] error: cannot access CommonClassA
[ERROR] -> [Help 1]**
Supporting details:
dependency defined in EmployeeBilling> pom.xml:
Other classes from common module seems accessible as no error observed
There are no other errors like Class not found/file not found.
The class CommonCLassA implements Serializable
Same error occurs from Eclipse as well as commond line
I am using M2E plugin
Tools:
jdk1.7.0_02
OS: Windows 7
Eclipse JUNO and apache-maven-3.1.0
Thanks in advance!
If project builds properly using eclipse compiler then it should work with Maven.
Few things to check if its not working with maven:
Manually check in repository that jar is installed properly and it contains your class file.
Try to build project using locally installed Maven instead of maven in eclipse.
Set -DskipTest=true while installing your jar, as it can cause issues at times.
If these steps don't work then show us your pom.
With no more information it's hard to find the cause. But I also had this problems now and then, and there are some things which could go wrong:
Are you using the right JAVA version (everywhere) ?
... and the right java PROVIDER? (Oracle, IBM, OpenJDK) In my case it's often this issue, I'm sometimes bound to IBM JDK, although I try to use Oracle where I can and this sometimes breaks my build.
Is the right maven dependency VERSION used? If you depend on it multiple times, and all in the same (lower than root) dept of dependencies, Maven will just "choose" a version. It could be that thát version is incompatible with your code of thát particular dependency
Skipping tests sometimes WORKS! It has something to do with maven phases and getting stuff ready for using it elsewhere.
Good luck :)
I had the same problem. Even the jar dependency has the required class files. Finally I deleted the local maven repo and restarted the build. Now it worked without any issue.
It looks like you are using an old version of maven-compiler-plugin (v2.3.2).
I suggest you upgrade it to 3.x. it won't magically fix your issue but it will definitely give you better / more detailed error message.
Now, i have a project which runs fine on my windows computer. But after I copied it to a linux computer, when compiling it reports following error:
Failed to execute goal on project alert: Could not resolve dependencies for project com.cloud.ras:alert.
The POM for com.external:commons-logging:jar:1.0.4.1 is missing, no dependency information available
The POM for com.external:freemarker:jar:2.3.4 is missing, no dependency information available
The POM for com.external:log4j:jar:1.2.14 is missing, no dependency information available
The POM for com.soa.lib:eBoxServiceCommon:jar:2.5.3 is missing, no dependency information available
but i have copied these jars to the maven repository. And can anyone give me a help?
You should NOT copy JARs in the first place. That's Maven job to resolve the dependencies for you.
It would be helpful if you explain the reason why you need to use your own groupId e.g. com.external in the first place i.e. commons-logging is from Apache but you use com.external as its groupId.
If you really insist on wanting to use your own groupId, at least download the JAR and install it using Maven. See here:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html.
I have a project in which the maven-enforcer rule fails with a multi-module build using non-unique snapshots (which are annoyingly the only kind of snapshot supported in Maven 3).
For example, assume -> is a "depends on" relationship, and:
Module-A -> Module-B -> Module-C
Module-A -> Module-C
and that Module B and Module C are present in the snapshot repository as unique builds. All declared Module versions in the POM are currently 1.0-SNAPSHOT.
Now, building Module A fails:
mvn -pl Module-A install
results in:
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce) # Module-A ---
[ERROR]
Dependency convergence error for com.vivosys.project:Module-C:1.0-SNAPSHOT paths to dependency are:
+-com.vivosys.project:Module-A:1.0-SNAPSHOT
+-com.vivosys.project:Module-B:1.0-20111228.032527-8
+-com.vivosys.project:Module-C:1.0-SNAPSHOT
and
+-com.vivosys.project:Module-A:1.0-SNAPSHOT
+-com.vivosys.project:Module-C:1.0-20111228.032527-6
The transitive dependency is resolved as a non-unique snapshot build, but the direct dependency is resolved as a unique snapshot build.
I am using maven 3.0.3, maven-enforcer 1.0.1. The repository is Artifactory 2.4.2 using the unique snapshots option (as recommended by Artifactory since Maven 3 no longer supports non-unique snapshots).
Solutions?
Update: Looks like artifactory allows overriding the maven client behavior and storing the non-unique snapshot in the repository. However, for some reason Artifactory does not recommend this (see the "Maven 3" blurb at http://wiki.jfrog.org/confluence/display/RTF/Local+Repositories) so other solutions are still welcome.
This bug has been fixed (MENFORCER-118) and released in version 1.1.
You have hit this enforcer plugin bug (raised as enhancement).
Perhaps, strictly as a workaround you can explicitly declare the transitive dependency C as a dependency of A?
The only solution available until MENFORCER-118 is resolved appears to be to configure the repository server to use non-unique snaphots. In Artifactory, this can be done via: Admin, Repositories, select the snapshot repository and choose Edit. Then select Nonunique under Maven Snapshot Version Behavior.