[#MNG-2962] (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.

Maven 2

(False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.

Created: 25/Apr/07 04:04 AM Updated: 03/Jul/08 07:06 PM

Component/s:

Dependencies

Affects Version/s:

2.0.6

Fix Version/s:

2.0.11

Time Tracking:

Not Specified

File Attachments:

m2.0.6-failing-compile-machineC.log (92 kB)
2.

m2.0.6-working-compile-machineB.log (243 kB)

Environment:

windows

Issue Links:

Related

This issue is related to:

~~MNG-3259~~ Regression: Maven drops dependencies in multi-module build

Complexity:

Intermediate

Description

« Hide

Since m2.0.6 builds that work perfectly on linux machine A and sometimes even on a windows machine B, breaks on another windows machine C.

We have some "false transitive dependencies": transitive dependencies that should be direct dependencies.
(We currently do this to avoid having to duplicate the version number as the different projects don't have a common superpom.)
Making those dependencies direct dependencies fixes the problem with windows machine C, but the real problem is that the guy on linux machine A should get the problems too, before committing.

The compiler plugin version is locked down to 2.0.2, but are using maven 2.0.6. This did not occur in maven 2.0.5.

Attached you'll find the "mvn -X install" logs of the 2 windows machines.

The log of machine C is specifically interesting, as it shows "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the classpath in the compiler plugin:

[DEBUG] Adding managed depedendencies for unknown:atlas-spring
...
[DEBUG] org.springframework:spring-beans:jar:2.0.2:compile
...

[DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes
.. (no org.springframework:spring-beans:jar:2.0.2)

Machine B instead has instead this at the classpath log part:

[DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes
...
C:\Documents and Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Geoffrey De Smet added a comment - 25/Apr/07 04:07 AM

There is thread @user called "m2.0.6 with false transitive dependencies fails on windows, works on linux":
http://www.nabble.com/m2.0.6-with-false-transitive-dependencies-fails-on-windows%2C-works-on-linux-tf3643824.html#a10176290

[ Permlink | « Hide ]

Jerome Lacoste added a comment - 25/Apr/07 04:31 AM

in your fail build log:

be.schaubroeck.atlas:atlas-spring:test-jar:tests:0.4.0-SNAPSHOT:test (selected for test)
commons-logging:commons-logging:jar:1.1:test (applying scope: compile)
be.schaubroeck.atlas:atlas-core:jar:0.4.0-SNAPSHOT:test (applying scope: compile)
commons-lang:commons-lang:jar:2.2:test (applying scope: compile)
org.springframework:spring-beans:jar:2.0.2:test (applying scope: compile)
org.springframework:spring-beans:jar:2.0.2:compile (selected for compile)
org.springframework:spring-context:jar:2.0.2:test (applying scope: compile)

notice how spring-beans jar is both as test and compile scope. This doesn't happen in the working one.

Are you 100% sure that your poms are completely identical on both machines, including local caches ?

Why is working machine has this in the logs:

+[DEBUG] Skipping disabled repository schaubroeck-dev
+[DEBUG] maven-compiler-plugin: resolved to version 2.0.2 from repository central

[ Permlink | « Hide ]

Geoffrey De Smet added a comment - 25/Apr/07 09:00 AM

At one point, machine A and machine C removed their local repo's and made sure they had the same poms (with "svn update"), nevertheless machine A would build and machine C would not.

Between machine B and machine C we used the same poms and our settings.xml differ little or not, there are no claims of a repository.

I have no explenation why machine B would skip our dev repo (and not our deploy repo) and machine C didn't.
Our dev repo does not contain org.springframework:spring-beans whatever (no meta data about it either).

[ Permlink | « Hide ]

Geoffrey De Smet added a comment - 25/Apr/07 09:04 AM

However, if we - instead of adding the false transitive dependences - removed the test-jar dependency it would also build on machine C (if test-compiling was disabled at least):

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>atlas-spring</artifactId>
<type>test-jar</type>
</dependency>

If m2.0.6 fixed the unrandomizing handling of "the dependency path resolution", how can the path differ between machines?
It looks like a randomizing factor has crept into transitive dependencies combined with compile en test scope?

[ Permlink | « Hide ]

John Casey added a comment - 03/Jul/08 07:06 PM

Pushing to 2.0.11 so we can have a smaller set of high-value issues to target for the next release (2.0.10).