--------------------------------------------------
From: "Stefan Bodewig" <bode...@apache.org>
Sent: Tuesday, March 09, 2010 12:53 AM
To: <general@gump.apache.org>
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
On 2010-03-09, Bill Barker <billwbar...@verizon.net> wrote:
Don't think this is going to help. It's complaining about the
installed POM, not the artifact from the mvnrepo proxy.
It's complaining about "Plugin's descriptor" which I guess not to be the
POM but some sort of descriptor contained withing the jar.
No, it's the POM. The maven-fortress-plugin runs with a goal of 'install'
against the public local repo, so copies it's POM there as well as the jar
file. Then M2 running on say excalibur-pool-impl sees it in the local repo,
and thinks it has it already. It then opens the POM, sees the wrong version
number and throws a hissy fit.
It's possible that restoring the jar, but removing the 'install' goal on
maven-fortress-plugin will trick M2 into getting the proxied POM, but the
built plugin. I'm still working through how the mvnrepo proxy works, so
this is just a guess.
The jar itself has been downloaded a few minutes before the build of
excalibur-pool-impl so the installed version has been provided by the
proxy.
It shouldn't have been, unless the project that downloaded it used
separateLocalRepository.
This is guesswork, I know.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
