You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Reinhard Nägele <Re...@mgm-tp.com> on 2009/02/09 08:40:33 UTC
Resolved Version Weirdness
Hello,
We have a multi-module project which transitively uses Commons Logging. We do not use it directly ourselves and so did not explicitly declare it as a dependency. So far, this has not been a problem. But for some reason, something must have changed over the weekend. I started our application and got a NoClassDefFoundError because org.apache.commons.logging.LogFactory was missing.
I then checked the following:
- Maven dependencies in Eclipse (using m2eclipse) showed commons-logging-1.1
- The dependency hierarchy and dependency:tree showed commons-logging-1.1
as the winner (amongst 1.0, 1.0.3, 1.0.4, 1.1, 1.1.1)
. dependency:copy copied commons-logging-1.1.jar
- The Jar plugin wrote commons-logging-1.1.1 into the manifest.
So, the problem is that either the Jar plugin or the Dependency plugin is wrong. Don't they use the same mechanism in order to determine the classpath? Naturally, I would expect the latest version to win. I don't understand why this happened all of a sudden. Nothing has changed here, and all our plugin versions are locked.
For now, I fixed the problem by explicitly adding commons-logging-1.1.1 as a dependency, but I don't really like this.
I'd appreciate any insight into what's going on here.
Thanks,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Resolved Version Weirdness
Posted by Reinhard Nägele <Re...@mgm-tp.com>.
Thanks for the insight, Brian. The culprit might indeed be a test dependency. I'll verify this. I originally checked for missing direct dependencies, but I might have to do that again.
Reinhard
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Tuesday, February 10, 2009 2:42 PM
To: Maven Users List
Subject: RE: Resolved Version Weirdness
Sounds to me like a classic case of not specifying your direct dependencies. Some other pom changed and introduced a transitive change breaking something you actually depend on. Run mvn dependency:analyze on your projects, if it says you are missing direct dependencies, you should fix them.
Yes, dependency-plugin and jar-plugin use the same resolution -- that is core hands the artifact list over to the plugins when they start. The dependency-plugin get the test scope to start which includes everything, perhaps some test dependency you have slightly changed and is influencing the dependency tree as seen by it.
-----Original Message-----
From: Reinhard Nägele [mailto:Reinhard.Naegele@mgm-tp.com]
Sent: Monday, February 09, 2009 2:41 AM
To: users@maven.apache.org
Subject: Resolved Version Weirdness
Hello,
We have a multi-module project which transitively uses Commons Logging. We do not use it directly ourselves and so did not explicitly declare it as a dependency. So far, this has not been a problem. But for some reason, something must have changed over the weekend. I started our application and got a NoClassDefFoundError because org.apache.commons.logging.LogFactory was missing.
I then checked the following:
- Maven dependencies in Eclipse (using m2eclipse) showed commons-logging-1.1
- The dependency hierarchy and dependency:tree showed commons-logging-1.1
as the winner (amongst 1.0, 1.0.3, 1.0.4, 1.1, 1.1.1)
. dependency:copy copied commons-logging-1.1.jar
- The Jar plugin wrote commons-logging-1.1.1 into the manifest.
So, the problem is that either the Jar plugin or the Dependency plugin is wrong. Don't they use the same mechanism in order to determine the classpath? Naturally, I would expect the latest version to win. I don't understand why this happened all of a sudden. Nothing has changed here, and all our plugin versions are locked.
For now, I fixed the problem by explicitly adding commons-logging-1.1.1 as a dependency, but I don't really like this.
I'd appreciate any insight into what's going on here.
Thanks,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Resolved Version Weirdness
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Sounds to me like a classic case of not specifying your direct dependencies. Some other pom changed and introduced a transitive change breaking something you actually depend on. Run mvn dependency:analyze on your projects, if it says you are missing direct dependencies, you should fix them.
Yes, dependency-plugin and jar-plugin use the same resolution -- that is core hands the artifact list over to the plugins when they start. The dependency-plugin get the test scope to start which includes everything, perhaps some test dependency you have slightly changed and is influencing the dependency tree as seen by it.
-----Original Message-----
From: Reinhard Nägele [mailto:Reinhard.Naegele@mgm-tp.com]
Sent: Monday, February 09, 2009 2:41 AM
To: users@maven.apache.org
Subject: Resolved Version Weirdness
Hello,
We have a multi-module project which transitively uses Commons Logging. We do not use it directly ourselves and so did not explicitly declare it as a dependency. So far, this has not been a problem. But for some reason, something must have changed over the weekend. I started our application and got a NoClassDefFoundError because org.apache.commons.logging.LogFactory was missing.
I then checked the following:
- Maven dependencies in Eclipse (using m2eclipse) showed commons-logging-1.1
- The dependency hierarchy and dependency:tree showed commons-logging-1.1
as the winner (amongst 1.0, 1.0.3, 1.0.4, 1.1, 1.1.1)
. dependency:copy copied commons-logging-1.1.jar
- The Jar plugin wrote commons-logging-1.1.1 into the manifest.
So, the problem is that either the Jar plugin or the Dependency plugin is wrong. Don't they use the same mechanism in order to determine the classpath? Naturally, I would expect the latest version to win. I don't understand why this happened all of a sudden. Nothing has changed here, and all our plugin versions are locked.
For now, I fixed the problem by explicitly adding commons-logging-1.1.1 as a dependency, but I don't really like this.
I'd appreciate any insight into what's going on here.
Thanks,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org