"http://maven.apache.org/release-notes.html" wrote:MNG-3220 - There is now a new scope for importing managed dependencies. See here{1} and here{2} for details. Please note that the use of this scope will break backwards compatibility with older Maven versions. If you use this, you should use the maven-enforcer-plugin to require a minimum maven version of 2.0.9

"http://maven.apache.org/release-notes.html" wrote:MNG-3220 - There is now a new scope for importing managed dependencies. See here{1} and here{2} for details. Please note that the use of this scope will break backwards compatibility with older Maven versions. If you use this, you should use the maven-enforcer-plugin to require a minimum maven version of 2.0.9

"pgier" wrote:Are you using the import scope in ejb3? I'm not sure how maven 2.0.8 would handle import scope, either an error or unpredictable behaviour I would guess.

Yeah, we're not using "import" scope in EJB3.

So I'm still at a loss as to what's up with this issue.

I suppose in the meantime we should introduce a fail-fast by requiring Maven 2.0.9 in the Enforcer Configuration for EJB3 Core.

S,ALR

Does the tree work ok without the "includes" parameter? That's really weird behaviour and looks like a bug. Something in the dependency resolution must have changed in 2.0.9 that messed up the dependency plugin.

"pgier" wrote:Does the tree work ok without the "includes" parameter? That's really weird behaviour and looks like a bug. Something in the dependency resolution must have changed in 2.0.9 that messed up the dependency plugin.

You mean does "dependency:tree" work without "includes"? Sure.

I don't think I've found enough Context to provide Maven with a useful bug report. Either way, this isn't the behaviour (intended or bug) that I'd expect from a point release.

"#maven" wrote:(03:04:49 PM) ALR: Hi, #Maven. I've found a difference in dependency resolution between 2.0.8 and 2.0.9, and was hoping someone could help me nail down an isolated use case to submit as a bug report.(03:05:49 PM) Brian: ALR: what's the difference?(03:06:04 PM) ALR: Brian: Preparing a Pastebin(03:06:08 PM) Brian: the only major change i can think of is that the order in the pom is preserved now making it deterministic(03:06:59 PM) ALR: Brian: http://pastebin.com/d7e7a4297(03:07:02 PM) Brian: we worked pretty hard to ensure there were no regressions between .8 and .9 so my money's on that(03:07:56 PM) Brian: i don't understand what the issue is based on the paste(03:07:58 PM) ALR: Brian: In that code snippit are two sections, the first is using 2.0.8, the second is 2.0.9.(03:08:32 PM) ALR: Brian: In 2.0.8 "org.jboss.microcontainer:jboss-container" is found as a dependency, in 2.0.9 it is not.(03:08:47 PM) ALR: Brian: Same machine.(03:09:21 PM) Brian: ALR do you want it to be found?(03:09:22 PM) ALR: Brian: And as help:describe shows, same version of the dependency plugin.(03:09:33 PM) ALR: Brian: No, I don't want it to be found.(03:09:55 PM) Brian: ok, can you paste the full tree output from both? (no -Dincludes)(03:10:05 PM) ALR: Brian: Sure, one moment.(03:12:18 PM) ALR: Brian: 2.0.8, then 2.0.9, separated by whitespace: http://pastebin.com/d778daed2(03:15:36 PM) Brian: ALR, i'm confused. You said you don't want jboss-container to be found and that it's not found in 2.0.9...what's the problem?(03:15:51 PM) ALR: Brian: That is *is* found in 2.0.8.(03:16:21 PM) ALR: Brian: What I want should be irrelevant; my concern is that the build is dependent upon the version of Maven being used.(03:17:08 PM) ALR: Brian: So if I'm using 2.0.9, and someone else on my project is still on 2.0.8, we have incompatible build results.(03:17:53 PM) Brian: ALR: i'm sure it's the ordering, if we find the right dependency and change the order in the pom it will be consistent(03:18:37 PM) Brian: in <2.0.8 the dependency ordering was dependent on the natural hashset order, which meant it could change if you moved jdks. In 2.0.9+, it's a linkedhashset and the order in the pom is preserved(03:19:09 PM) ALR: Brian: I see. You understand why this confuses me for a point release? :)(03:19:43 PM) ALR: Brian: This makes 2.0.9 not backward-compatible with 2.0.8.(03:20:12 PM) ALR: Brian: Unless you consider 2.0.8 handling a bug ;)(03:20:38 PM) Brian: ALR it was a tough call but it was causing far more issues as it was(03:20:54 PM) Brian: most of the time it's not an issue, but in edge cases like this it shows up(03:21:28 PM) ALR: Brian: Thanks very much again for your help. I'll take a look at the ordering of the transitives.(03:21:39 PM) Brian: i'm still comparing the trees here(03:21:45 PM) ALR: Brian: Ah, cool(03:24:09 PM) Brian: you don't have any exclusions?(03:24:28 PM) Brian: i can see in one system, the container comes from the jboss-as-jmx dependency but not in the other(03:24:34 PM) ALR: Brian: I'm sure we do :)(03:26:18 PM) ALR: Brian: Yes, that's very odd..(03:26:34 PM) ALR: Brian: Same version of jboss-as-jmx at that.(03:26:38 PM) Brian: yeah(03:26:47 PM) Brian: does that have an exclusion in it?(03:27:55 PM) Brian: jdcasey: ping(03:28:05 PM) jdcasey: ?(03:28:19 PM) ALR: Brian: No. http://pastebin.com/d72663242(03:28:42 PM) Brian: i'm looking at this output from the jboss build and i think the issue is because we made the order deterministic in 2.0.9 but i haven't put my finger on it yet(03:29:09 PM) Brian: jdcasey, here's the output: http://pastebin.com/d778daed2 2.0.8 on top, 2.0.9 on bottom.(03:29:21 PM) Brian: 2.0.8 has the jboss-container artifact, 2.0.9 doesn't(03:30:38 PM) Brian: jdcasey, it's coming from the jboss-as-jmx dependency but both maven versions have selected the same version of that dependency yet one is missing the container(03:31:05 PM) jdcasey: Brian: you may need to run with -X and capture the collection output in the debug logs to see what's happening there...it's possible an exclusion or something is getting triggered that wasn't before(03:31:24 PM) Brian: that's kinda what i was thinking(03:32:04 PM) ALR: Brian, jdcasey: I don't see the exclusion: Ã¯Â»Â¿http://pastebin.com/d72663242(03:32:33 PM) jdcasey: Brian: I didn't think we'd made provided-scope dependencies transitive yet?(03:32:41 PM) jdcasey: that provided scope maybe the key(03:33:09 PM) jdcasey: in any case, there's not enough information in that output to tell(03:33:17 PM) jdcasey: you need the full -X output for each, IMO(03:33:23 PM) jdcasey: and it'll be fun to pick out, too(03:33:26 PM) jdcasey: count on that(03:34:29 PM) ALR: Brian, jdcasey: k(03:42:52 PM) ALR: Brian, jdcasey: 2.0.8 http://pastebin.com/d20c5d35d(03:43:58 PM) ALR: Brian, jdcasey: 2.0.9 http://pastebin.com/d3143b227