Hi,
Based on earlier discussion [1] I would like to propose that we start
a new "Apache JCR Commons" subproject within Jackrabbit. See below
what this could mean in practice. As usual, comments are welcome!
COMPONENTS
The JCR Commons subproject would take over the development and
maintenance of the following components:
* jackrabbit-jcr-commons
* jackrabbit-jcr-tests
* jackrabbit-jcr-benchmark
* jackrabbit-jcr-rmi
* jackrabbit-jcr-servlet
* jackrabbit-webdav
* jackrabbit-jcr-server
* jackrabbit-classloader
* jackrabbit-ocm
* jackrabbit-ocm-nodemanagement
This would leave the jackrabbit-core component and the deployment
packages (webapp, jca, standalone) as the clear core of the remaining
Jackrabbit repository project. For now I think the SPI layer is so
close in scope to the repository implementation that we should keep it
close to the core. The text-extractors component has very limited use
outside Jackrabbit (especially now that Apache Tika is available), so
I'd keep it with the repository implementation until we can phase it
out entirely in favor of using Tika. Everything else goes to the JCR
Commons subproject.
Note that the webdav component is a bit special in that it actually
doesn't have much to do with JCR, so eventually it might be useful to
find a good home for it for example in Apache HttpComponents. Anyway,
for now I think the best home for it is still within Jackrabbit, and
by moving it to the commons subproject we give it a better chance to
evolve without ties to the Jackrabbit core release cycle.
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 create the following new mailing lists for the
subproject: commons-{user,dev,[EMAIL PROTECTED] Again,
following the example of Apache Commons in how to organize the mailing
lists (for example use a [rmi] subject prefix for all messages
regarding JCR-RMI) is probably a good idea.
* 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 new commons-commits@ 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 new
commons-dev@ list.
[1] http://markmail.org/message/dmvi7dtjeknkiuzl
BR,
Jukka Zitting
