--------------------------------------------------
From: "Stefan Bodewig" <bode...@apache.org>
Sent: Wednesday, March 10, 2010 12:27 AM
To: <general@gump.apache.org>
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
first of all: it worked ;-)
Yes, I didn't look to see that Gump was still running when I replied, so saw
the old page :(.
On 2010-03-10, Bill Barker <billwbar...@verizon.net> wrote:
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.
Yes, but it installs it as -SNAPSHOT version, not the released version
the excalibur projects have been looking for.
Then M2 running on say excalibur-pool-impl sees it in the local repo,
and thinks it has it already.
Shouldn't be since it has the wrong version.
Yeah, wondered about that, but couldn't see where it was getting the file
from, so I guess your right, and it is packaged with the plugin.
It then opens the POM, sees the wrong version number and throws a
hissy fit.
I still think it must be something inside the jar. 8-)
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.
Let me try to help you out WRT the proxy.
In general the proxy really only acts as a proxy using a few hard-coded
paths to identify known Maven repos based on the request's pathinfo.
Every <jar> in a Gump descriptor will publish a jar or POM to the repo
proxy after the project containing it has finished. POMs that don't use
the <jar>-hack will not be published to the proxy at all. Most of the
time this means mvn projects will see the original POMs of the released
versions but get the latest jars.
If you have any ideas why portals-pluto-trunk can't find it's parent, I'd
love to know them (but this is just to migrate projects off of the 1.0
release, so isn't really important now that castor is building). In
particular, if there was an access-log (that I haven't found), this would be
great. The mvnrepo log doesn't show it at all, but looks like it only logs
"200 OK" requests.
Of course, I'll do the grunt-work if I only knew the right grunt ;).
It looks as if such a combination would cause trouble for Maven plugins
since the jar has embeded version information (at least that's my
understanding of it).
From: "Stefan Bodewig" <bode...@apache.org>
Sent: Tuesday, March 09, 2010 12:53 AM
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.
No, it has just been looking for a non-SNAPSHOT version since the plugin
build has only installed a -SNAPSHOT.
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
