cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [RANT] This Maven thing is killing us....
Date Wed, 05 Jul 2006 00:25:52 GMT
Ralph,

Thanks for this, it's very helpful.

On 5/07/2006 6:59 AM, Ralph Goers wrote:
> However, this isn't even the biggest problem that has been hampering the 
> Cocoon community. It is that there seems to be at best a 50% chance of 
> getting a Maven 2 based Cocoon build to work due to dependencies failing 
> to download from repositories.  Cocoon also consistently uses snapshot 
> versions of some of its dependencies. While this isn't desirable, it is 
> a fact of life.  From Cocoon's perspective we really need to treat them 
> like they are a "private" release - i.e. they weren't formally released 
> from wherever they came from, but we don't want to have to download them 
> at every build since they will never change.

The first thing I'd suggest is for those having problems to try another 
mirror. I know requiring everyone to do that is a pain and not a long 
term solution, but I'd like to see how much that reduces the problem.

Regarding private releases, this is entirely possible just by giving 
them a version that isn't in the form of a snapshot. eg. if it is jetty 
6.0-SNAPSHOT, use 6.0-cocoon-1, 6.0-cocoon-2.

We'd considered this on the asf repository list: 
http://mail-archives.apache.org/mod_mbox/www-repository/200606.mbox/%3c31cc37360606062345n4a1dcd8eq1a5277590b858c33@mail.gmail.com%3e

However, this changes the use case a bit, since it considered those only 
to be needed for development and full releases would be released against 
full releases of their dependencies.

It depends on how you use them as to the best solution here. I assume 
that they are customised for cocoon, so they shouldn't be considered to 
be the same as the original. In that case, I'd suggest you release them 
under your own groupID (maybe org.apache.cocoon.thirdparty) so that they 
don't conflict (bearing in mind that someone will transitively receive 
both that and the original if they are both used). I'm assuming this 
isn't the case as you are only bundling these modified versions into a 
distributable app, not as part of a reusable component?

Hope this helps,
Brett

-- 
Brett Porter <brett@apache.org>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

Mime
View raw message