geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Apache Maven Repo Issue for 1.1 release
Date Wed, 24 May 2006 17:10:12 GMT

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).


> Thanks,
>    Aaron
> On 5/24/06, 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
>> '' to ''. 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 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
>> to is not supported
>>             at
>> org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect
>> (
>>             at
>> org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse
>> (
>>             at  
>> org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded
>> (
>>             at org.apache.commons.httpclient.HttpMethodBase.execute
>> (
>>             at org.apache.commons.httpclient.HttpClient.executeMethod
>> (
>>             at org.apache.commons.httpclient.HttpClient.executeMethod
>> (
>>             at org.apache.maven.wagon.providers.http.HttpWagon.get
>> (
>>             ...
>>      Invalid Redirect URI from:
>> org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar
>> to:
>> 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/
>> 2) Plan on removing the from our
>> file when the 1.1 release is tagged.
>> 3) Review the "permanence" of the other repo sites (codehaus,
>> mortbay, ibiblio) currently referenced by etc/
>> 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

View raw message