Re: Apache Maven Repo Issue for 1.1 release

[Donald Woods]

Inline

Kevan Miller wrote:

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

+1 to the Maven download bundle.

--kevan

Thanks,
   Aaron

On 5/24/06, Kevan Miller <[EMAIL PROTECTED]> 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)

(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

at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded

smime.p7s
Description: S/MIME Cryptographic Signature