The purpose of this rave content-services sandbox project is to provide groundwork implementation for the content services proposal as copied below. This proposal is also online available here: http://t.co/lbwHngXQ [PROPOSAL] Rave content services - introduction 03/15/2012 10:02 AM From: Ate Douma (ate@douma.nu) List: org.apache.incubator.rave-dev Hi Ravers, I'd like to introduce a proposal for adding content services to Rave. The plan is to extend and enhance Rave with a content services layer to dynamically manage and retrieve content, markup, etc, as well as custom domain models through a hierarchical content repository based on JCR (Java Content Repository) [1] and Apache Jackrabbit [2]. Such JCR based content services will allow storing and managing Rave web front-end elements like pages, templates, layouts, headers, images, styling and component view rendering fragments dynamically in a central back-end, as well as other (custom) domain objects to be used by Rave itself or through widgets. Note: the term 'content' in 'Java Content Repository' is quite loosely defined: anything can be regarded as 'content' and a JCR typically stores much more than 'web' content as such. The Airavata podding uses it for storing and maintaining workflow and services definitions in the Airavata Registry, and Wookie has an optional back-end storage on JCR as well. Which might come in handy for Rave too ;) Our initial plan was to prepare a code donation from our Hippo Site Toolkit product (HST) [3] which already provides these features through a very light-weight multi-site development and management framework. Furthermore HST provides a context mapping engine which will be very useful and IMO also needed for Rave (but later). However, after thorough review and some prototyping work, we've come to the conclusion that providing this through a code donation will require too much upfront work (on our side) to refactor out critical but only Hippo specific functionalities. So, we've decided to go about the other way around: to start from scratch within Rave itself. This also allows and invites the Rave community to participate from the start, for a more agile process and better alignment of architecture and functionality. But we can still use Hippo HST, which is open-source and available under ASL 2.0 license, as example and reference for this purpose. Initial participation and contributions for this work will be provided by myself, Ard, Unico and Marijan (all Hippo employees), and we have explicit time and budget allocated to work on this over the coming months. And of course we hope others from the community are willing to chime in and participate as well. This proposal has also preliminary been reviewed and discussed with Matt Franklin and Bill Donaldson of MITRE. They support the proposal and are willing to commit resources to the proposal if agreed to by the community. I intend this email only as introduction: I will provide more detailed information on the goals, tasks and possible future work in separate emails. Below I just briefly describe an overview of the groundwork tasks, features and concrete modules we intent to start working on. And, as this proposal will/should impact and enhance the Rave architecture, we propose to start initially in a Rave sandbox, building on top of Rave, not fork it. This will thereby also help pull and push the Rave modularization, extendability and configuration discussions. Future merging back into the main Rave project, or as optional extension modules is of course the intend but something to be decided when the time is right. The features and tasks we intend to work on for the groundwork are: * A separate rave-jcr war module exposing and bundling a Apache Jackrabbit content repository through a service layer. * A rave-jcr-config module (or modules) providing low-level JCR administrative features like for import/export, and content type and content bootstrap and upgrade functionality. * A rave-jcr-ocm module for Object Content Mapping (OCM) support. Jackrabbit already provides a jackrabbit-ocm module for this [4], but it can use some improvements and enhancements, as well as generic Rave integration support. Furthermore, the latest released jackrabbit-ocm is a bit outdated and still on JCR 1.0 level, while a newer but unreleased JCR 2.0 based version is available in their sandbox. So we intend collaboration on this with the Jackrabbit developers (note: Ard is also Jackrabbit committer). * Introducing a HMVC pattern based solution for rave-web-*. This feature/enhancement definitely requires separate discussion, beyond and independent of this proposal for which I'll open a separate thread. It boils down to replacing or enhancing the current single (simple) Spring MVC interaction for the portal to a Hierarchical MVC (HMVC) based solution. This will be needed to support a more generic and extensible front-end layout, aggregation and rendering architecture. For quick info, see [5], and I'll come back on this shortly with more details. * A rave-web-jcr module which will provide concrete OCM and JCR service usages to manage, map and access Rave web features like pages, regions, menus, layouts and (view) templates stored in the JCR. This module also will support and make use of a HMVC pattern as described above. * A rave-jcr-console war module. To help working with a JCR engine, both for development as well as for low-level runtime administration, we'll provide an optional rave-jcr-console war module, which can be used to browse and modify a JCR store at runtime on node/property level as well as provide (pluggable) front-end tooling for import/export node type and namespace management, etc. For this purpose Hippo provides an open-source ASL 2.0 licensed JCR/Jackrabbit web console [6], without any Hippo specific dependencies. Note: this is not a code donation but can be easily leveraged as optional tooling for Rave. Beyond this, at a later stage we also intend to provide or start work on a "context mapping engine" (CME) for Rave, but first we like to get the above groundwork features in place. Assuming lazy consensus on the overall goals (not the details), I intend to start with creating a content-services sandbox project early next week. And Ard, Unico and Marijan are expected to engage in the effort starting from April 1st. Any feedback on this initial proposal and further engagement on discussing these features and their implementation are of course very much appreciated! Regards, Ate [1] http://www.jcp.org/en/jsr/summary?id=283 [2] http://jackrabbit.apache.org/ [3] https://wiki.onehippo.com/display/CMS7/7.7+Hippo+Site+Toolkit+Wiki+pages [4] http://jackrabbit.apache.org/object-content-mapping.html [5] http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/ [6] http://svn.onehippo.org/repos/hippo/hippo-jcr/console/trunk