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