You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Wendy Smoak <ws...@gmail.com> on 2007/08/10 18:14:28 UTC
Bad links on plugin index page
Any idea what happened to the plugin index page? It was published
today (Aug 10) and all the links are to anchors on the index page
rather than to the plugin site. For example:
http://maven.apache.org/plugins/index.html#maven-compiler-plugin/
instead of http://maven.apache.org/plugins/maven-compiler-plugin/
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Dennis Lundberg <de...@apache.org>.
Dennis Lundberg wrote:
> Brett Porter wrote:
>> Using the latest of everything doesn't correct the problem - seems
>> like there's still a bug.
>
> OK, we need to track this down ASAP.
I have committed a (temporary) fix for this problem. To get a better
solution I have started a thread about this on doxia-dev@maven.a.o
called "Solving links and anchors". Please head over there if you have
opinions about this.
>> I also had to skip the tests in the doxia-sitetools to get it to build.
>
> What error did you get? Tests run fine for me on Windows.
>
>> I reverted to 2.0-beta-5, which works but skips the two pages
>> (index.xml.vm and download.apt.vm). All should be ok once synced.
>
> Thanks Brett.
>
>> - Brett
>>
>> On 11/08/2007, at 10:28 AM, Brett Porter wrote:
>>
>>> My fault, I published it, assuming whatever would be in the repo
>>> would be correct.
>>>
>>> I'll try building the latest of everything and do it again.
>>>
>>> - Brett
>>>
>>> On 11/08/2007, at 2:52 AM, Dennis Lundberg wrote:
>>>
>>>> Wendy Smoak wrote:
>>>>> Any idea what happened to the plugin index page? It was published
>>>>> today (Aug 10) and all the links are to anchors on the index page
>>>>> rather than to the plugin site. For example:
>>>>> http://maven.apache.org/plugins/index.html#maven-compiler-plugin/
>>>>> instead of http://maven.apache.org/plugins/maven-compiler-plugin/
>>>>
>>>> It's due to someone using the wrong doxia SNAPSHOTs when publishing
>>>> the site. I don't know if the ones in the snapshot repo are wrong or
>>>> if someone built them themselves, but we should get new snapshots
>>>> deployed anyway.
>>>>
>>>> It is unfortunate that our site build relies on a SNAPSHOT version
>>>> of maven-site-plugin, which in turn relies on SNAPSHOT versions of
>>>> doxia. But we're at least eating our own dog food :-)
>>>>
>>>> --
>>>> Dennis Lundberg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plexus container 1/2 artifact problems [was: Bad links on plugin
index page]
Posted by Dennis Lundberg <de...@apache.org>.
Brett Porter wrote:
>
> On 16/08/2007, at 8:42 AM, Kenney Westerhof wrote:
>
>>
>>> 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.
>
> Yeah, I think addressing this in doxia with exclusions is the right way
> to go. I might also look at special casing this in surefire if it's
> appropriate.
I tried adding exclusions in the plexus-velocity dependency, but p-c-a
is being dragged in from other places as well. I haven't spent much time
analyzing dependency graphs in Maven, so I'm going to leave this as it
is for now. The problem only occurs when I use surefire-2.3.1-SNAPSHOT.
>
>> First having one archive,
>> then 2, then one again, that's asking for problems ;)
>
> +1 :)
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plexus container 1/2 artifact problems [was: Bad links on plugin index page]
Posted by Brett Porter <br...@apache.org>.
On 16/08/2007, at 8:42 AM, Kenney Westerhof wrote:
>
>> 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.
Yeah, I think addressing this in doxia with exclusions is the right
way to go. I might also look at special casing this in surefire if
it's appropriate.
> First having one archive,
> then 2, then one again, that's asking for problems ;)
+1 :)
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plexus container 1/2 artifact problems [was: Bad links on plugin
index page]
Posted by Kenney Westerhof <ke...@apache.org>.
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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plexus container 1/2 artifact problems [was: Bad links on plugin
index page]
Posted by Dennis Lundberg <de...@apache.org>.
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?
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?
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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plexus container 1/2 artifact problems [was: Bad links on plugin
index page]
Posted by Kenney Westerhof <ke...@apache.org>.
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Plexus container 1/2 artifact problems [was: Bad links on plugin index page]
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:kenney@apache.org]
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plexus container 1/2 artifact problems [was: Bad links on plugin
index page]
Posted by Kenney Westerhof <ke...@apache.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Brett Porter <br...@apache.org>.
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.setSourc
>> e(Ljava/lang/String;)V
>> at
>> org.codehaus.plexus.component.discovery.DefaultComponentDiscoverer.cr
>> eateComponentDescriptors(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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Jason van Zyl <ja...@maven.org>.
On 12 Aug 07, at 5:11 AM 12 Aug 07, Brett Porter wrote:
>
> On 12/08/2007, at 5:07 AM, Dennis Lundberg wrote:
>
>> Brett Porter wrote:
>>> Using the latest of everything doesn't correct the problem -
>>> seems like there's still a bug.
>>
>> OK, we need to track this down ASAP.
>
> Cool, thanks for taking care of it.
>
>>
>>> I also had to skip the tests in the doxia-sitetools to get it to
>>> build.
>>
>> What error did you get? Tests run fine for me on Windows.
>
> 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.cre
> ateComponentDescriptors(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.
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Brett Porter <br...@apache.org>.
On 12/08/2007, at 5:07 AM, Dennis Lundberg wrote:
> Brett Porter wrote:
>> Using the latest of everything doesn't correct the problem - seems
>> like there's still a bug.
>
> OK, we need to track this down ASAP.
Cool, thanks for taking care of it.
>
>> I also had to skip the tests in the doxia-sitetools to get it to
>> build.
>
> What error did you get? Tests run fine for me on Windows.
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.creat
eComponentDescriptors(DefaultComponentDiscoverer.java:68)
I'll poke around some more.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Dennis Lundberg <de...@apache.org>.
Brett Porter wrote:
> Using the latest of everything doesn't correct the problem - seems like
> there's still a bug.
OK, we need to track this down ASAP.
> I also had to skip the tests in the doxia-sitetools
> to get it to build.
What error did you get? Tests run fine for me on Windows.
> I reverted to 2.0-beta-5, which works but skips the two pages
> (index.xml.vm and download.apt.vm). All should be ok once synced.
Thanks Brett.
> - Brett
>
> On 11/08/2007, at 10:28 AM, Brett Porter wrote:
>
>> My fault, I published it, assuming whatever would be in the repo would
>> be correct.
>>
>> I'll try building the latest of everything and do it again.
>>
>> - Brett
>>
>> On 11/08/2007, at 2:52 AM, Dennis Lundberg wrote:
>>
>>> Wendy Smoak wrote:
>>>> Any idea what happened to the plugin index page? It was published
>>>> today (Aug 10) and all the links are to anchors on the index page
>>>> rather than to the plugin site. For example:
>>>> http://maven.apache.org/plugins/index.html#maven-compiler-plugin/
>>>> instead of http://maven.apache.org/plugins/maven-compiler-plugin/
>>>
>>> It's due to someone using the wrong doxia SNAPSHOTs when publishing
>>> the site. I don't know if the ones in the snapshot repo are wrong or
>>> if someone built them themselves, but we should get new snapshots
>>> deployed anyway.
>>>
>>> It is unfortunate that our site build relies on a SNAPSHOT version of
>>> maven-site-plugin, which in turn relies on SNAPSHOT versions of
>>> doxia. But we're at least eating our own dog food :-)
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Brett Porter <br...@apache.org>.
Using the latest of everything doesn't correct the problem - seems
like there's still a bug. I also had to skip the tests in the doxia-
sitetools to get it to build.
I reverted to 2.0-beta-5, which works but skips the two pages
(index.xml.vm and download.apt.vm). All should be ok once synced.
- Brett
On 11/08/2007, at 10:28 AM, Brett Porter wrote:
> My fault, I published it, assuming whatever would be in the repo
> would be correct.
>
> I'll try building the latest of everything and do it again.
>
> - Brett
>
> On 11/08/2007, at 2:52 AM, Dennis Lundberg wrote:
>
>> Wendy Smoak wrote:
>>> Any idea what happened to the plugin index page? It was published
>>> today (Aug 10) and all the links are to anchors on the index page
>>> rather than to the plugin site. For example:
>>> http://maven.apache.org/plugins/index.html#maven-compiler-plugin/
>>> instead of http://maven.apache.org/plugins/maven-compiler-plugin/
>>
>> It's due to someone using the wrong doxia SNAPSHOTs when
>> publishing the site. I don't know if the ones in the snapshot repo
>> are wrong or if someone built them themselves, but we should get
>> new snapshots deployed anyway.
>>
>> It is unfortunate that our site build relies on a SNAPSHOT version
>> of maven-site-plugin, which in turn relies on SNAPSHOT versions of
>> doxia. But we're at least eating our own dog food :-)
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Brett Porter <br...@apache.org>.
My fault, I published it, assuming whatever would be in the repo
would be correct.
I'll try building the latest of everything and do it again.
- Brett
On 11/08/2007, at 2:52 AM, Dennis Lundberg wrote:
> Wendy Smoak wrote:
>> Any idea what happened to the plugin index page? It was published
>> today (Aug 10) and all the links are to anchors on the index page
>> rather than to the plugin site. For example:
>> http://maven.apache.org/plugins/index.html#maven-compiler-plugin/
>> instead of http://maven.apache.org/plugins/maven-compiler-plugin/
>
> It's due to someone using the wrong doxia SNAPSHOTs when publishing
> the site. I don't know if the ones in the snapshot repo are wrong
> or if someone built them themselves, but we should get new
> snapshots deployed anyway.
>
> It is unfortunate that our site build relies on a SNAPSHOT version
> of maven-site-plugin, which in turn relies on SNAPSHOT versions of
> doxia. But we're at least eating our own dog food :-)
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Bad links on plugin index page
Posted by Dennis Lundberg <de...@apache.org>.
Wendy Smoak wrote:
> Any idea what happened to the plugin index page? It was published
> today (Aug 10) and all the links are to anchors on the index page
> rather than to the plugin site. For example:
>
> http://maven.apache.org/plugins/index.html#maven-compiler-plugin/
> instead of http://maven.apache.org/plugins/maven-compiler-plugin/
It's due to someone using the wrong doxia SNAPSHOTs when publishing the
site. I don't know if the ones in the snapshot repo are wrong or if
someone built them themselves, but we should get new snapshots deployed
anyway.
It is unfortunate that our site build relies on a SNAPSHOT version of
maven-site-plugin, which in turn relies on SNAPSHOT versions of doxia.
But we're at least eating our own dog food :-)
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org