I had these problems with the dependency plugin too. They kept coming in through other dependencies that didn't have the exclusions. To stop/detect that, I made an enforcer execution for detecting when the new containers have crept in and warn me.
________________________________ From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Tue 8/14/2007 9:34 AM To: Maven Developers List Subject: Re: Plexus container 1/2 artifact problems [was: Bad links on plugin index page] 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]
