geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
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.


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

View raw message