Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Fri, 26 Sep 2008 02:22:44 +1000
From: David Crossley <crossley@apache.org>
To: general@incubator.apache.org
Subject: Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution
 channels like the central Maven repository
Message-ID: <20080925162244.GC27676@igg.indexgeo.com.au>
References: <510143ac0809092334j274d0055xd7ed34ea758dca0f@mail.gmail.com>
 <510143ac0809240640l17118fe0ve2bece31e745f0cf@mail.gmail.com>
 <48DA844D.90908@rowe-clan.net> <20080925004012.GG14889@igg.indexgeo.com.au>
 <48DAE717.1000805@rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48DAE717.1000805@rowe-clan.net>
User-Agent: Mutt/1.4.2.3i

William A. Rowe, Jr. wrote:
> David Crossley wrote:
> > William A. Rowe, Jr. wrote:
> > 
> > [snip]
> >> I liked the way you put the question; it's not up to incubator project to
> >> set the rules for Maven.  If the maven PMC decides that these incubator
> >> releases don't belong in the primary repository, that's their call.  But
> >> this vote makes clear that the incubator has nothing to say about an
> >> artifact's distribution once the release vote is finalized.
> > 
> > Other than this important statement from
> > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
> > "Releases for podling MUST be distributed through
> > www.apache.org/dist/incubator/podling"
> 
> Exactly.  This doesn't state that "Releases for podling must be EXCLUSIVELY
> distributed through www.a.o/dist/incubator/podling".
> 
> It was a statement to quit posting the release artifacts in the un-mirrored
> corners, and that these are the first initial official release paths.
> Previously these were scattered throughout on un-mirrored servers in a
> fairly haphazard way.
> 
> So they must be shipped through /dist/incubator/podling or there is no
> assertion that they are releases.  Once there, they travel unassisted
> to dozens of mirror servers and on to other locations and uses.

We are getting to the nub of it.

This is beyond any particular build system.

We have an infrastructure already, with our mirror system.

If every project would distribute not only their primary
source releases from there, but also secondary artefacts
(e.g. jars, poms, ivys, zips, whatever). These all would
have signatures and checksums.

Then any build system can rely on that distribution
mirror infrastructure.

There is a beautiful gem with our mirror system that
i reckon is underutilised. It can generate an xml list
of the preferred mirrors. Therefore it can be automated.

Over the last few days i have been taking some steps
to solve our Apache Forrest plugin distribution system,
and use the mirror system to do it. Made good progress
on that with an Ant-based build. 
(If someone wants a demo of the core part then i can
stick it in my home directory.)

Anyway my point is that any build system (Maven, Ivy,
Ant, etc.) can rely on our mirror infrastructure if
we populate it in a consistent manner. They can replicate
it from the official source to maintain their own mirrors.
We don't need to worry.

In the Incubator case, we do need to find ways
to make people aware of what they are using.

-David


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org