Re: Apache Maven Repo Issue for 1.1 release
On Wed, May 24, 2006 at 04:05:40AM -0400, Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. I've noticed some strange behavior that maybe someone can explain. I can reach people.apache.org fine from a web browser, and a maven new4 new5 build starts fine, but at some point during the build I start to get connection timeout messages from Maven because people.apache.org starts refusing connections from my machine on port 80. I can still connect fine from other hosts, so I'm wondering if people.a.o has some sort of dynamic rate limiting that maven is running afoul of. After a few minutes, people.a.o starts accepting connections again, but if I try another maven build I get put back on the blacklist. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Please, please, please! An even better solution would be to add the dependencies to the source control tree so that I get everything I need from svn co. Thanks, Toby
Re: Apache Maven Repo Issue for 1.1 release
+1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
I added a program I was noodling on into sandbox. Its in sandbox/releasetools/trunk/src/java/org/apache/geroinimo/releasetools/VersionVerifier.java Its not complete and very rough but it effectively grinds through the entire G tree and extracts all dependencies G has on external projects. I started adding code to go to the maven repos and get a current list of projects but haven't finished it. David Blevins had a good suggestion that this could be used to build a project.xml that could declare all the dependencies so you could run maven against the project.xml and download all dependencies at once. If this helps you have at. Matt Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
Can we stick the repo in our zone? -dain On May 24, 2006, at 7:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
On May 24, 2006, at 10:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. I'm pretty iffy on putting a maven repo repro into svn. For one, it becomes incorrect anytime a version is upgraded (I guess this isn't so bad, if it's properly described...). Also, I don't care for automated task to be doing a commit into svn and I don't want to be doing the commit by hand on a weekly basis. I also don't care for large binary data being held in svn. I typically have the entire geronimo tree checked out. This would (unless we use an entirely different tree) potentially add multiple repo repro's into geronimo svn. I'd be all for the weekly unstable build process being used to package all necessary dependencies and make them available for download along with the unstable build src. The repo should be cleaned out prior to every unstable build. I'm also in favor of having a maven repo download available that corresponds to the 1.1 release and is available on the download page (if possible). --kevan Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
Inline Kevan Miller wrote: On May 24, 2006, at 10:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. I'm pretty iffy on putting a maven repo repro into svn. For one, it becomes incorrect anytime a version is upgraded (I guess this isn't so bad, if it's properly described...). Also, I don't care for automated task to be doing a commit into svn and I don't want to be doing the commit by hand on a weekly basis. I also don't care for large binary data being held in svn. I typically have the entire geronimo tree checked out. This would (unless we use an entirely different tree) potentially add multiple repo repro's into geronimo svn. I'd be all for the weekly unstable build process being used to package all necessary dependencies and make them available for download along with the unstable build src. The repo should be cleaned out prior to every unstable build. I'm also in favor of having a maven repo download available that corresponds to the 1.1 release and is available on the download page (if possible). +1 to the Maven download bundle. --kevan Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache Maven Repo Issue for 1.1 release
I think it would be in our best interest for the long term using Maven to host our own repository, which is backed up by svn. By default the projects will point to the http:// base of our repository (say http://svn.apache.org/repos/asf/geronimo/repository/ m2 or http://svn.apache.org/repos/asf/geronimo/repository/m1). This will do the normal dependency download, and will work for most folks out of the box. But, users can also check out the repository to a local directory, add a bit of settings.xml to add a local repository and then run offline. I believe going forward we *must* do something about the dependency on remote sites that affect our build process. IMO the remoteness that Maven brings is a blessing and a curse. To have 100% reliable and repeatable builds we need to isolate (and really remove) the remoteness. --jason On May 24, 2006, at 10:09 AM, Dain Sundstrom wrote: Can we stick the repo in our zone? -dain On May 24, 2006, at 7:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/ repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work- around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
It sounds like there are really two issues IIUC. The first is that normal development is impeded because the sites mirroring Maven content are dynamic and because of circumstances beyond anyone's control give sporadic results. The second is the ability for a user to rebuild Geronimo n.n after we ship it because of problem number 1. Let me provide some input on these problems in reverse order. Regarding rebuilding shipped version of Geronimo I think having a saved copy of the repo used to build Geronimo makes sense. For 1.0 I still have that repo on stan.gbuild.org. Here is the size of the repo: -rw-r--r-- 1 hogstrom users 428521800 Dec 21 21:24 geronimo-1.0-maven-repo.tar.gz 428 MB doesn't seem too bad but is still a big chunk to download. We should make this available but if we get on the train for multiple point releases this may add up pretty quickly. I'm not an Infra person so I don't know if that's a number they would have concern about. Back to the first problem. I have a system that I use that rsyncs to the servers named in maven.remote property about 3 times a day. It works pretty good for me since my builds are at highly available LAN speeds. I think this would be the right solution for us as a team. At some point the instability will cause more and more people to do exactly what were discussing which may end up being at least part of the problem (doesn't solve the dynamic nature of the problem though). Would it make sense to use the same rsync commands I'm using for my internal repo and have one of the GBuild machines host this function? We have control of them and it is consistent with the way we're building and doing continuous builds anyway. Or can we simply put an HTTP server up and point to the maven repo used for GBuild anyway? Matt Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
Does that 428MB include the Geronimo distributioons themselves? I suspect so -- I use a 60MB .tar.bz2 (repository+source tree) for Geronimo 1.0 build tests (though I think that builds OpenEJB too so the size would vary if we use OpenEJB binaries). Thanks, Aaron On 5/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: It sounds like there are really two issues IIUC. The first is that normal development is impeded because the sites mirroring Maven content are dynamic and because of circumstances beyond anyone's control give sporadic results. The second is the ability for a user to rebuild Geronimo n.n after we ship it because of problem number 1. Let me provide some input on these problems in reverse order. Regarding rebuilding shipped version of Geronimo I think having a saved copy of the repo used to build Geronimo makes sense. For 1.0 I still have that repo on stan.gbuild.org. Here is the size of the repo: -rw-r--r-- 1 hogstrom users 428521800 Dec 21 21:24 geronimo-1.0-maven-repo.tar.gz 428 MB doesn't seem too bad but is still a big chunk to download. We should make this available but if we get on the train for multiple point releases this may add up pretty quickly. I'm not an Infra person so I don't know if that's a number they would have concern about. Back to the first problem. I have a system that I use that rsyncs to the servers named in maven.remote property about 3 times a day. It works pretty good for me since my builds are at highly available LAN speeds. I think this would be the right solution for us as a team. At some point the instability will cause more and more people to do exactly what were discussing which may end up being at least part of the problem (doesn't solve the dynamic nature of the problem though). Would it make sense to use the same rsync commands I'm using for my internal repo and have one of the GBuild machines host this function? We have control of them and it is consistent with the way we're building and doing continuous builds anyway. Or can we simply put an HTTP server up and point to the maven repo used for GBuild anyway? Matt Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
Your right Aaron...my recollection was that this was a clean repo. After looking at the zip there was some CTS, other Geronimo artifacts, etc. Here is the current size after doing an rm -rf on three dirs that are not relevant. -rw-r--r-- 1 hogstrom users 52499153 May 24 12:50 processrepo.tar.gz That's cheap. Thanks! Aaron Mulder wrote: Does that 428MB include the Geronimo distributioons themselves? I suspect so -- I use a 60MB .tar.bz2 (repository+source tree) for Geronimo 1.0 build tests (though I think that builds OpenEJB too so the size would vary if we use OpenEJB binaries). Thanks, Aaron On 5/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: It sounds like there are really two issues IIUC. The first is that normal development is impeded because the sites mirroring Maven content are dynamic and because of circumstances beyond anyone's control give sporadic results. The second is the ability for a user to rebuild Geronimo n.n after we ship it because of problem number 1. Let me provide some input on these problems in reverse order. Regarding rebuilding shipped version of Geronimo I think having a saved copy of the repo used to build Geronimo makes sense. For 1.0 I still have that repo on stan.gbuild.org. Here is the size of the repo: -rw-r--r-- 1 hogstrom users 428521800 Dec 21 21:24 geronimo-1.0-maven-repo.tar.gz 428 MB doesn't seem too bad but is still a big chunk to download. We should make this available but if we get on the train for multiple point releases this may add up pretty quickly. I'm not an Infra person so I don't know if that's a number they would have concern about. Back to the first problem. I have a system that I use that rsyncs to the servers named in maven.remote property about 3 times a day. It works pretty good for me since my builds are at highly available LAN speeds. I think this would be the right solution for us as a team. At some point the instability will cause more and more people to do exactly what were discussing which may end up being at least part of the problem (doesn't solve the dynamic nature of the problem though). Would it make sense to use the same rsync commands I'm using for my internal repo and have one of the GBuild machines host this function? We have control of them and it is consistent with the way we're building and doing continuous builds anyway. Or can we simply put an HTTP server up and point to the maven repo used for GBuild anyway? Matt Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other
