geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
Date Thu, 31 Mar 2005 20:54:15 GMT
I think this is a good start in the right direction. The need for 
demonstrable oversight is clear and if anything I would like to 
strengthen those processes not loosen them. Some of that is already 
built into Maven and we should use those capabilities.

More comments inline, all fine tuning.

--
Jeremy

Geir Magnusson Jr. wrote:
> Here's a proposal for the Geronimo PMC regarding running a maven 
> repository for the project here at the ASF.  The basic problem is that 
> there are many at the ASF, including board members, that believe that we 
> shouldn't publish or distribute software that isn't created at the ASF.  
> I was one of those until yesterday, when I thought it through for a 
> bit.   I've started some private conversations with those I know have 
> issues with the idea to get feedback early, and in parallel we can work 
> out a plan and incorporate their feedback if this has a chance of 
> acceptance (I think it should...).
> 
> Note that there is a "slippery-slope" argument against this for which 
> there is no good answer other than the pragmatic "lets minimize risk and 
> see what happens"....
> 
> Motivation
> ----------
> 
> I) We want a fast, controlled source of project dependencies to make it 
> easy and fast to build Geronimo.
> 
>  We are able to include binary jars from other outside projects in our 
> official releases, because
> 
> a) it's clear that we are the publisher of the combined work
>    that is our release
> b) there has been sufficient oversight by the releasing PMC
>   to ensure that the licenses and re-distribution terms for
>   the third party jars are appropriate
> 
> In order to do have a maven repo that includes third party jars, we must
> 
> a) make it clear that we are *NOT* the publisher of the third party
>    jars, but we are just redistributing it under appropriate terms
>    as defined by the publisher
> b) we can demonstrate that the PMC had oversight and control
>    over the contents of the repository to monitor  the content,
>    license and re-dist terms
> 
> II) For any community member that is interested in tracking the external 
> dependencies (and there is an increased awareness in commercial users 
> due to liability and indemnification issues), the following proposal 
> provides a clear stream of specific messages never buried in commit 
> noise to allow an observer to track changes in project dependencies.
> 
> So the proposal is then to create a maven repository for the use of the 
> Geronimo project.  If the basic idea is sound, lets iron out the 
> details.  Here's a start :
> 
> Structure
> ---------
> - maven structure
> - include a license file for each third-party artifact we have

This is a normal feature of a Maven repo. We should also require that an 
appropriate POM is installed so that contributors can be identified.

> - include a INFO file for each third-party artifact containing
>     - source of jar
>     - source's statement about redistribution
> 

We should also include INFO for each release identifying the third-party 
jars that it uses. This means there is an easier place to look than the 
content of a distribution.

> Contents
> --------
> - top-level index page clearly describing purpose and intent of 
> repository (0)
> - all third-party dependencies needed by current and recent-in-time 
> build (1)
> - snapshot versions of Geronimo build artifacts for "sister" projects 
> like OpenEJB that have a [soon-to-go-away] tight dependency on core 
> geronimo code
> - release versions of Geronimo build artifacts (maybe not..)
> 
> (0) can we add a short note put into our maven output that says 
> "Geronimmo 3rd party dependencies will be sourced from the 
> project-specific geronimo repository" or such?
> (1) Do we want to keep old stuff?  I think not - I think we'd want to be 
> good ASF citizens to keep disk space usage to what is really needed.  If 
> you need an older version, for some reason, you can slog it out of 
> ibiblio or the original source.
> 

I think we should keep as much history as possible, at least the 
dependencies for all maintained branches.

> 
> Oversight and Process
> ---------------------
> - writable by all Geronimo committers only
> - openly readable (2)
> - any addition or update to the repo requires that
>   - INFO and LICENSE are added/updated if needed
>   - email sent to dev@ to inform community (3)
>   - change accepted by PMC by lazy consensus
> - any third-party jar that is not an official release (like OpenEJB 
> these days) but built from source by a Geronimo developer (w/ or w/o 
> patches) must be marked with "SNAPSHOT" to make it clear that jar isn't 
> a release from the originating project, nor an attempt by the Geronimo 
> project to create a release or a distributable for another project.

A grey area here is the "we need release 4.0.1 + these three patches" 
scenario (for example, as an emergency security fix). This would not be 
a SNAPSHOT but a revision/timestamp build of the project we depend on. I 
think clear notification, lazy consensus by the PMC and a plan to 
migrate to an offical release would be sufficient oversight - we just 
need to be clear about what is happening.

> - infrastructure will be informed when we create this to ensure that in 
> the event someone has a problem with something coming from our repo, 
> they'll be aware and can just yank offending artifact, and know to 
> inform the geronimo PMC about the issue
> 
> (2) for now...
> (3) we can find technology solutions to reduce the work later - lets 
> focus on the oversight process
> 
> I think that covers the basics.  Comments?
> 
> geir
> 


Mime
View raw message