Dennis Lundberg wrote:
Thanks for looking into this Kenney.
Are you saying that that the problem is really in maven itself, and
version 2.0.7 in particular as it uses the shading thingy?
Yes, the problem is in maven itself. It uses a shaded embedder but that's okay.
2.0.7 uses plexus-container-default 1.0-alpha-9-stable-1, which is very old and
predates
the split of plexus-container-default to p-c-d and p-c-a, so maven 2.0.7 doesn't
know anything about plexus-container-api.
The shaded version of p-c-d has the same problem: it doesn't list p-c-a,
so if a dependency uses an older version of p-c-d or p-c-a (after the split,
before the shading plugin existed), the p-c-a doesn't get filtered out,
or even aligned to the version of p-c-d.
Or is there something that we can do in doxia to fix it? Should we
update to a version of plexus-velocity that uses the latest
plexus-container-default?
That would work; or add a depMgt section specifying p-c-d and p-c-a as scope
provided
in the doxia poms. Possibly just an exclude on the plexus-velocity dep for
p-c-d/p-c-a,
but we need to come up with a more general solution. First having one archive,
then 2, then one again, that's asking for problems ;)
-- Kenney
Kenney Westerhof wrote:
I just committed a fix in the mojo sandbox for the shade plugin:
instead of removing the dependencies, it marks them provided.
That should make sure all versions line up if a transitive
dep brings in a 'removed' artifact.
I'm not sure where the removal of provided scoped deps takes place;
probably as soon as they're encountered, so this might not work.
Again, as I've argued numerous times in the past, if provided scope
was transitive this would not be a problem (and loads of other problems
would go away aswell). The filter on provided scope should be in
get(Runtime|Test)(ClasspathElements|Dependencies), not in the artifact
resolver.
-- Kenney
Kenney Westerhof wrote:
Hi,
I added a sleep to the test and quickly copied /tmp/surefire*tmp
to examine them.
The following 2 entries in the surefire tmp file are the cause:
surefire45886tmp:classPathUrl.30=/home/forge/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-20/plexus-component-api-1.0-alpha-20.jar
surefire45886tmp:classPathUrl.24=/home/forge/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-30/plexus-container-default-1.0-alpha-30.jar
The dependency on plexus-velocity 1.1.5 brings in the dep on p-c-a
1.0-alpha-20
which isn't filtered out by maven 2.0.7, since that uses p-c-d
1.0-alpha-9-stable-1
which is from the era where plexus-component-api didn't exist.
If maven were to use a newer version of plexus with the 2 separate jars,
this problem would go away.
If maven were to use the latest version of plexus with the shaded jar,
then the proper solution in the shading/merging is NOT to just remove
dependencies that
are merged, but still list them but with scope provided so they are
filtered out.
In any case, maven 2.0.7 will not work when projects have
dependencies on the 2-jar
version of the container, unless the p-c-a is filtered out
everywhere, or all
p-c-d poms with shading have p-c-a listed as provided (so that 2 jars
will/might be used
in compilation since provided is only filtered out transitively, but
at least the p-c-a
and p-c-d versions will match).
So whether the test succeed depends on forkmode, even with 2.3. I
really can't get it
to work with 2.3 or 2.3.1 at all unless I set forkMode to never - to
me, they behave
exactly the same. It may depend on what snapshots you have in your
local repo though.
If someone has a working test with surefire 2.3 and forkmode=once
I'd like to get a hold of those surefire*tmp files to see exactly
which jars
are used.
-- Kenney
Brett Porter wrote:
On 12/08/2007, at 6:56 PM, Jason van Zyl wrote:
Looks like a bad plexus snapshot on my end, since it's fine on the
zone too.
testRender(org.apache.maven.doxia.siterenderer.DefaultSiteRendererTest)
Time elapsed: 0.275 sec <<< ERROR!
java.lang.NoSuchMethodError:
org.codehaus.plexus.component.repository.ComponentDescriptor.setSource(Ljava/lang/String;)V
at
org.codehaus.plexus.component.discovery.DefaultComponentDiscoverer.createComponentDescriptors(DefaultComponentDiscoverer.java:68)
I'll poke around some more.
Vincent already brought this up on the list a week or so ago. It's
a problem with surefire not pulling in the right version of plexus.
It should be using the version of plexus specific by the POM, not
the one Maven is running with. So simply forking the tests may do
the trick. But the isolated classloader no longer appears to do
what it was intended to do.
Odd. I've pinned the whole thing to 2.3, using the default forkMode
of once, since that works. It seems it is a regression in
2.3.1-SNAPSHOT, so I'll add it to the list.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
