Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
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.jarmaven-metadata-local.xml commons-openpgp-1.0-SNAPSHOT.pom Regards, Antoine Stefan Bodewig wrote: On 2010-03-16, Bill Barker billwbar...@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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
On 2010-03-19, Antoine Levy Lambert anto...@gmx.de wrote: On 2010-03-16, Bill Barker billwbar...@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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Friday, March 19, 2010 6:39 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-19, Antoine Levy Lambert anto...@gmx.de wrote: On 2010-03-16, Bill Barker billwbar...@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-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
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
On 2010-03-16, Bill Barker billwbar...@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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
On 2010-03-15, Bill Barker billwbar...@verizon.net wrote: -- From: Stefan Bodewig bode...@apache.org Sent: Sunday, March 14, 2010 10:20 PM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-13, Bill Barker billwbar...@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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Monday, March 15, 2010 8:01 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-15, Bill Barker billwbar...@verizon.net wrote: -- From: Stefan Bodewig bode...@apache.org Sent: Sunday, March 14, 2010 10:20 PM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-13, Bill Barker billwbar...@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-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
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
On 2010-03-13, Bill Barker billwbar...@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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Sunday, March 14, 2010 10:20 PM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-13, Bill Barker billwbar...@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-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
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Thursday, March 11, 2010 5:38 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-11, Bill Barker billwbar...@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-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
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
On 2010-03-11, Bill Barker billwbar...@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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
first of all: it worked ;-) 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. 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 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
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- 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
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. 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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- 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
