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
