atom feed15 messages in org.apache.jackrabbit.devApache JCR Commons
FromSent OnAttachments
Jukka ZittingDec 2, 2008 7:52 am 
Alexander KlimetschekDec 2, 2008 8:42 am 
Bertrand DelacretazDec 2, 2008 9:05 am 
Jukka ZittingDec 2, 2008 9:10 am 
Angela SchreiberDec 3, 2008 12:13 am 
Jukka ZittingDec 3, 2008 2:36 am 
Alexander KlimetschekDec 3, 2008 2:45 am 
Angela SchreiberDec 3, 2008 2:53 am 
Jukka ZittingDec 3, 2008 5:27 am 
Jukka ZittingDec 4, 2008 7:40 am 
Jukka ZittingDec 9, 2008 6:31 am 
Alexander KlimetschekDec 9, 2008 7:09 am 
Jukka ZittingDec 9, 2008 7:21 am 
Alexander KlimetschekDec 9, 2008 8:40 am 
Jukka ZittingDec 9, 2008 9:02 am 
Subject:Apache JCR Commons
From:Jukka Zitting (
Date:Dec 2, 2008 7:52:21 am


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!


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.


* 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.


* 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.


* Web site: The subproject will have its own web site at 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,commits} 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.