geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Apache Maven Repo Issue for 1.1 release
Date Wed, 24 May 2006 19:52:14 GMT
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 <matt@hogstrom.org> 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
>> >
>> >
>> >
>> >
>> >
>>
> 
> 
> 

Mime
View raw message