Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44AA6305.50908@apache.org>
Date: Tue, 04 Jul 2006 13:45:57 +0100
From: Steve Loughran <stevel@apache.org>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Maven Developers List <dev@maven.apache.org>
CC: dev@cocoon.apache.org
Subject: Re: [RANT] This Maven thing is killing us....
References: 
 <FDD5D99066749040AF9098A720E9897701CA1830@CIWMEXZSA0E.ex.ordersx.org>
 <98e4f1cd0607040434k1c0f7ddeo8e9ddf0899c15b7e@mail.gmail.com>
In-Reply-To: <98e4f1cd0607040434k1c0f7ddeo8e9ddf0899c15b7e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Torsten Curdt wrote:
> Sorry, for the cross-post ...but it seems we need a dialog here
> somehow. We now have two threads on two different mailing
> lists/communities that really should talk to each other.
> 
>> I propose to commit again all JARs into, say, cocoon/trunk/m2repo
>> and then tell Maven at build time to use that directory in the
>> checkout area as first repository server in the search list.
> 
> So where is the big difference? For every fresh checkout you download
> the jars from subversion.
> 
> Guys I have no solution at hand but let's not throw out the baby with
> the bath water. I would be good to summarize all the pain points and
> post them over in maven land. The pain being so bad that we are
> (somehow) considering going back to ant should be alarming enough.

Actually, speaking on behalf of the ant team, can I extend a big 
(tentative) welcome back :)


> Another point seems to be forgotten in this discussion so far - the
> legal aspects of distributing jars. Does the ASF want to re-distribute
> 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff
> during ApacheCon it seems we could have blocks providing bridging code
> to LGPL ...as long as we do not provide the jar and the block is
> optional. (Sylvain, did I summarize that correctly?)

There is always the option of a public yet locked down repository with 
the sun jars and/or the other external dependencies. Working on a 
sourceforge repo, we keep extra stuff under SCM, and have the dependency 
logic look there first.

you could even have an SCM-managed repo on sourceforge or codehaus for 
this other stuff, though it would be a somewhat public admission that 
the main repository has failed.

> I agree that the whole maven2 situation is currently far less than
> just acceptable ...but TBH I am not sure the maven team is (or was?)
> really aware of all the problems we have.
> 
> Maybe we can get a statement on the maven self-update and
> unreliable-messed-up-repository situation. From what it sounds they
> are working on it. So let's not work this out in our little cocoon
> corner but let's hear what they have to say.
> 

In a way, many of the stuff in M2 is experimental; a build tool that 
effectively encodes beliefs about how a project should be structured and 
delivered, focusing on component-based development instead of 
application dev. I also think its time to look at how well some of the 
experiment is working.

Personally, I always experience a bit of fear when adding a new 
dependency to a project. the repository stuff, and estimate a couple of 
hours to get every addition stable, primarily by building up a good 
exclusion list.

M2, and <m2:libraries> in ant, has changed the nature of the problem, 
from "what versions of what things do I need with this?" to "how much of 
this stuff do I really need?" and "why are my junit tests not compiling 
with an error about assertTrue not being known", the latter seguing into 
"where is junit3.7 coming from?".  Its a form of progress, but still 
painful. Similarly, keeping a repository cache under SCM does at least 
give you a structured layout for storing multiple versions of stuff 
under SCM, with flick-of-a-switch access to new versions. It just adds 
an extra step "pom creation/fixup" to the process.

Is it worse than before? Better? Or just, well, different? and if things 
are either worse or not as good as they could be, what can be changed?

One underlying cause seems to be pom quality. Open source software dev 
is a vast collection of loosely coupled projects, and what we get in the 
repository in terms of metadata matches this model. Each project 
produces artifacts that match their immediate needs, with POM files that 
appear to work at the time of publishing. Maven then caches those and 
freezes that metadata forever, even if it turns out that the metadata 
was wrong.  There's far better coherence within Gump, where the metadata 
is effectively maintained more by the gump team themselves than by the 
individual projects.

Question is, what to do about it? And if the m2 repository was an 
attempt to leave the problems of the M1 repository behind, has it worked?

-steve