Hi,
Thanks for all the comments, keep 'em coming! Here's an updated
version of the JCR Commons subproject proposal. This version should
address most of the concerns and issues that were raised.
COMPONENTS
The JCR Commons subproject would take over the development and
maintenance of the following components:
* jackrabbit-parent
* jackrabbit-jcr-tests
* jackrabbit-jcr-benchmark
* jackrabbit-jcr-rmi
* jackrabbit-jcr-servlet
* jackrabbit-classloader
* jackrabbit-ocm
* jackrabbit-ocm-nodemanagement
Most notably (and a bit surprisingly), the jcr-commons component would
remain with the core project for now to avoid complicating the
development workflow for issues that may range over component
boundaries. We may need to split the jcr-commons component to be able
to move parts of the code to the proposed subproject, but that's a
separate discussion that we don't need to solve now.
Similarly, the jcr-server and webdav components will be kept with core
for now until we have better idea about what to do there (see
JCR-417).
Compared to the previous proposal, I also decided to put the
jackrabbit-parent component into the commons subproject. The parent
POM does contain some core-specific parts, but I believe we can move
those back to the core components and make the parent POM contain only
truly Jackrabbit-wide information and settings.
For comparison, the following components would remain as the core
Jackrabbit project:
* jackrabbit-api
* jackrabbit-core
* jackrabbit-text-extractors
* jackrabbit-webdav
* jackrabbit-jcr-server
* jackrabbit-webapp
* jackrabbit-jca
* jackrabbit-spi
* jackrabbit-spi-commons
* jackrabbit-jcr2spi
* jackrabbit-spi2jcr
* jackrabbit-standalone
COMMUNITY
* Committers: For now there will be just a single set of Jackrabbit
committers. Later on we may want to consider adopting a "subproject
committer" concept for making it easier to grant someone committership
to just the commons components.
* PMC: The Jackrabbit PMC will govern also this new subproject.
DEVELOPMENT
* Initial code: The initial code for the new subproject would come
from the selected existing components in Jackrabbit trunk.
* Releases: Each component within the new subproject would have it's
own independent release cycle. To avoid confusion with the existing
1.x releases, the release numbering of the moved components would
start at 2.0. Since all these components are relatively small and
tightly scoped, it would probably be useful to keep their version
numbering down to just two levels, i.e. use x.y instead of x.y.z as
the numbering scheme.
INFRASTRUCTURE
* Web site: The subproject will have its own web site at
http://jackrabbit.apache.org/commons/. We might want to follow the
example of Apache Commons in organizing this web site.
* Mailing lists: We will use the existing
{user,dev,[EMAIL PROTECTED] mailing lists for the new
subproject. To make it easier to track topics about selected commons
components, we should adopt a practice of prefixing related email
subjects, for example using [rmi] for messages about JCR-RMI.
* Subversion: We create a new asf/jackrabbit/commons directory that
will contain all the code of the new subproject. Each component will
have it's own {trunk,branches,tags} structure within this subtree. For
example, the JCR-RMI component would be developed in
asf/jackrabbit/commons/jcr-rmi/trunk. All Jackrabbit committers will
have write access to this subtree. Notifications of commits to this
subtree will be sent to the [EMAIL PROTECTED] list.
* Issue tracker: We create separate Jira projects for each component
in the subproject. These projects will be grouped using a new "JCR
Commons" category in Jira. Update messages will be sent to the
[EMAIL PROTECTED] list.
BR,
Jukka Zitting
