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
