You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Bill Barker <bi...@verizon.net> on 2010/03/09 08:12:29 UTC
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Don't think this is going to help. It's complaining about the installed
POM, not the artifact from the mvnrepo proxy.
--------------------------------------------------
From: <bo...@apache.org>
Sent: Monday, March 08, 2010 10:58 PM
To: <co...@gump.apache.org>
Subject: svn commit: r920715 - /gump/metadata/project/excalibur.xml
> Author: bodewig
> Date: Tue Mar 9 06:58:35 2010
> New Revision: 920715
>
> URL: http://svn.apache.org/viewvc?rev=920715&view=rev
> Log:
> Maven 2.2 has become more picky about plugin versions or so it seems.
> Stop publishing the fortress plugin.
>
> Modified:
> gump/metadata/project/excalibur.xml
>
> Modified: gump/metadata/project/excalibur.xml
> URL:
> http://svn.apache.org/viewvc/gump/metadata/project/excalibur.xml?rev=920715&r1=920714&r2=920715&view=diff
> ==============================================================================
> --- gump/metadata/project/excalibur.xml (original)
> +++ gump/metadata/project/excalibur.xml Tue Mar 9 06:58:35 2010
> @@ -863,7 +863,7 @@
> <depend project="excalibur-fortress-meta"/>
>
> <home nested="fortress/plugin"/>
> - <jar name="target/maven-fortress-plugin-1.3.2-SNAPSHOT.jar"/>
> + <!--jar
> name="target/maven-fortress-plugin-1.3.2-SNAPSHOT.jar"/-->
>
> <!--nag from="Gump <dev@excalibur.apache.org>"
> to="scm@excalibur.apache.org"/-->
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Friday, March 19, 2010 6:39 AM
To: <ge...@gump.apache.org>
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
> On 2010-03-19, Antoine Levy Lambert <an...@gmx.de> wrote:
>
>>> On 2010-03-16, Bill Barker <bi...@verizon.net> wrote:
>
>>>> I was thinking of adding a localRepository="name" to the <mvn />
>>>> builder that allows projects to share a local repo when they can't be
>>>> trusted to use the central repo. These would be cleaned when Gump
>>>> finishes (or maybe on startup).
>
>> Is it the same like "installing" the snapshot artifacts in the local
>> ~/.m2 cache ?
>
> Yes, I think so. Only that we'd be using a directory other than ~/.m2
> that would get purged after the Gump run has finished.
>
Yes, that is the idea. It lets a group of projects that depend on each
other's snapshot artifacts to "install" them in a local cache where they can
then be found by M2, since M2 doesn't like to get snapshot artifacts from
any of the remote repos that are currently mirrored.
This would also be helpful for M2 projects that define their own remote repo
in the POM, that isn't mirrored, since they can't be trusted to use the
common local cache (because if they have a dependency on an Ant-built
project, and are the first to request it, it will get the versioned jar from
their remote repo, and then other M2 projects will use that jar instead of
the Gump-built jar).
This would have made setting up portals-pluto-trunk much easier, instead of
the sordid hack I used to convince Gump to make it the last project to
build.
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-19, Antoine Levy Lambert <an...@gmx.de> wrote:
>> On 2010-03-16, Bill Barker <bi...@verizon.net> wrote:
>>> I was thinking of adding a localRepository="name" to the <mvn />
>>> builder that allows projects to share a local repo when they can't be
>>> trusted to use the central repo. These would be cleaned when Gump
>>> finishes (or maybe on startup).
> Is it the same like "installing" the snapshot artifacts in the local
> ~/.m2 cache ?
Yes, I think so. Only that we'd be using a directory other than ~/.m2
that would get purged after the Gump run has finished.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Antoine Levy Lambert <an...@gmx.de>.
Hi,
Is it the same like "installing" the snapshot artifacts in the local
~/.m2 cache ?
I am looking at some of the stuff which is lying on my hard drive :
/Users/antoine/.m2/repository/org/apache/commons/commons-openpgp/1.0-SNAPSHOT
antoine-levy-lamberts-macbook:1.0-SNAPSHOT antoine$ ls
commons-openpgp-1.0-SNAPSHOT.jar maven-metadata-local.xml
commons-openpgp-1.0-SNAPSHOT.pom
Regards,
Antoine
Stefan Bodewig wrote:
> On 2010-03-16, Bill Barker <bi...@verizon.net> wrote:
>
>
>> I was thinking of adding a localRepository="name" to the <mvn />
>> builder that allows projects to share a local repo when they can't be
>> trusted to use the central repo. These would be cleaned when Gump
>> finishes (or maybe on startup).
>>
>
> Sounds like a good idea. It would probably solve the castor-xml case as
> well when castor-xml can share the local repository with castor-core.
>
> Stefan
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-16, Bill Barker <bi...@verizon.net> wrote:
> I was thinking of adding a localRepository="name" to the <mvn />
> builder that allows projects to share a local repo when they can't be
> trusted to use the central repo. These would be cleaned when Gump
> finishes (or maybe on startup).
Sounds like a good idea. It would probably solve the castor-xml case as
well when castor-xml can share the local repository with castor-core.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Monday, March 15, 2010 8:01 AM
To: <ge...@gump.apache.org>
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
> On 2010-03-15, Bill Barker <bi...@verizon.net> wrote:
>
>> --------------------------------------------------
>> From: "Stefan Bodewig" <bo...@apache.org>
>> Sent: Sunday, March 14, 2010 10:20 PM
>> To: <ge...@gump.apache.org>
>> Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
>
>>> On 2010-03-13, Bill Barker <bi...@verizon.net> wrote:
>
>>>> Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
>>>> that the 'central' repo is disabled for SNAPSHOTs (and it is looking
>>>> for a SNAPSHOT POM). So Maven never asks to get it (even though it is
>>>> there).
>
>>> Do I understand this correctly that with Maven 2.2 Gump will not be able
>>> to inject its own jars if the POM specifies a dependency on a SNAPSHOT
>>> version?
>
>> I think that this is a setting for 'central', that it disables
>> SNAPSHOT versions (understandable from the Maven prospective). It's
>> just that Maven won't download a SNAPSHOT version from 'central'.
>> Reactor builds with SNAPSHOT should still work.
>
> I see. SNAPSHOTs then will likely be pulled from different repositories
> and we'd need to make the Maven proxy intercept those as well.
>
Or, like for hudson, they just won't be found. I was thinking of adding a
localRepository="name" to the <mvn /> builder that allows projects to share
a local repo when they can't be trusted to use the central repo. These
would be cleaned when Gump finishes (or maybe on startup).
Then the projects could use a goal of 'install', and it looks like Maven
will accept it for another project that wants to depend on that SNAPSHOT
version.
>> Briefly thought of overriding this in either the local or global
>> settings, but then realized that I don't know enough about Maven to
>> get it right in the first 10 tries ;). That is why I was hoping that
>> there is still a Maven guru lurking here.
>
> Same here.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-15, Bill Barker <bi...@verizon.net> wrote:
> --------------------------------------------------
> From: "Stefan Bodewig" <bo...@apache.org>
> Sent: Sunday, March 14, 2010 10:20 PM
> To: <ge...@gump.apache.org>
> Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
>> On 2010-03-13, Bill Barker <bi...@verizon.net> wrote:
>>> Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
>>> that the 'central' repo is disabled for SNAPSHOTs (and it is looking
>>> for a SNAPSHOT POM). So Maven never asks to get it (even though it is
>>> there).
>> Do I understand this correctly that with Maven 2.2 Gump will not be able
>> to inject its own jars if the POM specifies a dependency on a SNAPSHOT
>> version?
> I think that this is a setting for 'central', that it disables
> SNAPSHOT versions (understandable from the Maven prospective). It's
> just that Maven won't download a SNAPSHOT version from 'central'.
> Reactor builds with SNAPSHOT should still work.
I see. SNAPSHOTs then will likely be pulled from different repositories
and we'd need to make the Maven proxy intercept those as well.
> Briefly thought of overriding this in either the local or global
> settings, but then realized that I don't know enough about Maven to
> get it right in the first 10 tries ;). That is why I was hoping that
> there is still a Maven guru lurking here.
Same here.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Sunday, March 14, 2010 10:20 PM
To: <ge...@gump.apache.org>
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
> On 2010-03-13, Bill Barker <bi...@verizon.net> wrote:
>
>> Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
>> that the 'central' repo is disabled for SNAPSHOTs (and it is looking
>> for a SNAPSHOT POM). So Maven never asks to get it (even though it is
>> there).
>
> Do I understand this correctly that with Maven 2.2 Gump will not be able
> to inject its own jars if the POM specifies a dependency on a SNAPSHOT
> version?
>
I think that this is a setting for 'central', that it disables SNAPSHOT
versions (understandable from the Maven prospective). It's just that Maven
won't download a SNAPSHOT version from 'central'. Reactor builds with
SNAPSHOT should still work.
Briefly thought of overriding this in either the local or global settings,
but then realized that I don't know enough about Maven to get it right in
the first 10 tries ;). That is why I was hoping that there is still a Maven
guru lurking here.
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-13, Bill Barker <bi...@verizon.net> wrote:
> Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
> that the 'central' repo is disabled for SNAPSHOTs (and it is looking
> for a SNAPSHOT POM). So Maven never asks to get it (even though it is
> there).
Do I understand this correctly that with Maven 2.2 Gump will not be able
to inject its own jars if the POM specifies a dependency on a SNAPSHOT
version?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Thursday, March 11, 2010 5:38 AM
To: <ge...@gump.apache.org>
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
> On 2010-03-11, Bill Barker <bi...@verizon.net> wrote:
>
>> If you have any ideas why portals-pluto-trunk can't find it's parent,
>
> It isn't even trying to download it. Since I don't know enough about
> Maven I can't say why a repository may get disabled, but
>
> [DEBUG] Skipping disabled repository central
> [DEBUG] portals-pom: using locally installed snapshot
> [DEBUG] Skipping disabled repository central
> [DEBUG] Using mirror: http://localhost:8192/maven2 (id: gump-central)
>
> sounds suspicios.
>
Yeah, downloaded the src distro for maven 2.2.1, and it is that it is that
the 'central' repo is disabled for SNAPSHOTs (and it is looking for a
SNAPSHOT POM). So Maven never asks to get it (even though it is there).
The work-arounds that I've seen are too complex for Gump, and the project is
largely dormant, so for the moment will just let it fail.
Of course, if there are any Maven gurus lurking here with better ideas,
would love to hear them.
>> 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.
>
> The proxy uses ju.logging and I think it should be logging to stdout by
> default which should make it end up in Gump's own log file (since this
> is the parent process). I can't promise it would log failed requests,
> though.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-11, Bill Barker <bi...@verizon.net> wrote:
> If you have any ideas why portals-pluto-trunk can't find it's parent,
It isn't even trying to download it. Since I don't know enough about
Maven I can't say why a repository may get disabled, but
[DEBUG] Skipping disabled repository central
[DEBUG] portals-pom: using locally installed snapshot
[DEBUG] Skipping disabled repository central
[DEBUG] Using mirror: http://localhost:8192/maven2 (id: gump-central)
sounds suspicios.
> 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.
The proxy uses ju.logging and I think it should be logging to stdout by
default which should make it end up in Gump's own log file (since this
is the parent process). I can't promise it would log failed requests,
though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Wednesday, March 10, 2010 12:27 AM
To: <ge...@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 <bi...@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" <bo...@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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Stefan Bodewig <bo...@apache.org>.
first of all: it worked ;-)
On 2010-03-10, Bill Barker <bi...@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.
> 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.
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" <bo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Tuesday, March 09, 2010 12:53 AM
To: <ge...@gump.apache.org>
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
> On 2010-03-09, Bill Barker <bi...@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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-09, Bill Barker <bi...@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.
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.
This is guesswork, I know.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org