geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Apache Maven Repo Issue for 1.1 release
Date Wed, 24 May 2006 19:29:27 GMT
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
control give sporadic results.  The second is the ability for a user to rebuild Geronimo n.n
we ship it because of problem number 1.  Let me provide some input on these problems in reverse

Regarding rebuilding shipped version of Geronimo I think having a saved copy of the repo used
build Geronimo makes sense.  For 1.0 I still have that repo on  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
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
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
end up being at least part of the problem (doesn't solve the dynamic nature of the problem
  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?


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: 

> to:  

> 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