gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Date Thu, 11 Mar 2010 04:08:38 GMT

From: "Stefan Bodewig" <>
Sent: Wednesday, March 10, 2010 12:27 AM
To: <>
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 <> 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" <>
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message