Improved demo project.
> This project depends on an ejb jar that isn't on repo. Any way we can use something else?
> This will make it impossible to make an IT for this since we can't redistribute the jar.
I replaced javax.ejb:ejb with an old version of jboss:jboss-j2ee and the problem still occurs - so far so good. Also removed the unnecessary parent pom of the root.
> I installed the jar and I can't reproduce this so far.
> I verified this on 2.0.7/8 and 2.1 using java 1.5. It seems ok with 1.6
As I said, fails with JDK 1.4.2 and 1.5.0, works for 1.6.0 - therefore I assume that a HashMap is involved when processing the sequence of the deps, since some internals of the HashMap changed in JDK 1.6 causing this effect - which should not make any difference for any algorithm using a HashMap, since it is an expected behaviour.
> I noticed that you had exclusions in various places for the artifact that is missing (xstream).
> Why are those exclusions there? If I remove them, then everything builds fine, but the
> order of resolution is slightly different.
This is typical for artifacts containing business delegates. Those artifacts are used in web clients and they may not include all dependencies used to implement the business logic on the server. The coincidence here is, that the excluded deps are not used at the client, should not be included in the resulting war and should not even be available as transitive dep. However, the excluded artifact is necessary for running the tests (or compiling, simply add a refernce to the missing class into the test code and the build fails earlier). With M205 Maven still provides this artifact as test dependency, while with M207 and M208 the dependency is suddenly gone.
Module 1 is in the real world basically a test framework on top of jMock and JUnit where we do not really care about all the deps it needs, since it is for test only.
You are also able to use a workaround by declaring the missing dependency explicitly in the POM to be used for test scope, but in our real build it does not really help, since then surefire in M207/M208 is missing the next class from a different artifact that should be available as transitive dep from the test framework.
Point is, that the algorithm calculating the deps and the classpaths in M207/M208 provides different results when run locally or from a parent.
BTW: Thanks for looking at this, it drives us really crazy.