Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44AE063C.1070809@apache.org>
Date: Fri, 07 Jul 2006 16:59:08 +1000
From: Brett Porter <brett@apache.org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Maven Developers List <dev@maven.apache.org>
Subject: Re: [RANT] This Maven thing is killing us....
References: 
 <FDD5D99066749040AF9098A720E9897701CA1830@CIWMEXZSA0E.ex.ordersx.org>
	 <98e4f1cd0607040434k1c0f7ddeo8e9ddf0899c15b7e@mail.gmail.com>
	 <1a5b6c410607040553r6c20b441j81ec638465d9f10d@mail.gmail.com>
	 <44AAD6C3.3050107@dslextreme.com>
	 <1a5b6c410607041722o2c9e0111g6983003db99ea937@mail.gmail.com>
	 <44AB5849.2030900@dslextreme.com> <44ABD500.1060609@apache.org>
 <5a2cf1f60607050832x10ebe10euc5623ba6e4f8fc5f@mail.gmail.com>
In-Reply-To: <5a2cf1f60607050832x10ebe10euc5623ba6e4f8fc5f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 6/07/2006 1:32 AM, jerome lacoste wrote:
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.

Yep, already have that for that very reason (calling it build number in 
hindsight was not the greatest choice :)

> 
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.

This seems like a good idea in theory, but our situation is different 
for the following reasons:
- we may not always have the source
- this assumes that the dependency list is used to build the project 
(which assumes they build with m2). We could take a stab at anything 
using ant by doing what gump does, though, so it's worth a shot.
- we are actually distributing the originally released artifact rather 
than rebuilding and repackaging like most distros. They also go ahead to 
test their repackaging, something we can't afford to do.

> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions

And it is almost impossible to build stuff that targetted older releases 
of the OS (look what happened with the various incompatible 
autoconf/automake releases, gcc2 -> 3 -> 4, etc).

Makes sense for a stable OS, not so much a build system.

> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.

I think we are already on the way to this. Better docs and tooling needed.

> 
> - use of provides and various other dependency markers (that's coming
> in m2 2.1 if I got it right)

Yup.

- Brett

-- 
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org