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