[
http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111795
]
Joerg Schaible edited comment on MNG-3259 at 10/29/07 4:47 AM:
---------------------------------------------------------------
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.
was:
Improved demo project.
> Regression: Maven drops dependencies in multi-module build
> ----------------------------------------------------------
>
> Key: MNG-3259
> URL: http://jira.codehaus.org/browse/MNG-3259
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 2.0.7, 2.0.8
> Reporter: Joerg Schaible
> Assignee: Brian Fox
> Priority: Blocker
> Fix For: 2.0.8
>
> Attachments: MNG-3259-2.zip, MNG-3259.zip
>
>
> Under some circumstances Maven "forgets" about test dependencies in
> multi-module builds. The affected module can be build only if the build is
> started from its local project directory. If the build is run from a parent
> directory, the test fails because of missing classes. This issue applies to
> M207 and recent M208-RC1, the project can be build without problems with M205
> (M206 is completely bogus). The problem was for us already the show stopper
> for M207 and I thought with some of the now resolved issues it has been gone,
> but I was wrong. I did not report it earlier, because I was never able to
> reproduce the problem with a minimal build ... until now and it took me about
> 3 days to create a demonstrating multi module project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
