Revision as of 16:56, 24 September 2007

JCR Mangement (JCRM)

JCR Management will provide pluggable JCR (http://en.wikipedia.org/wiki/Content_repository_API_for_Java) implementations through the EMF API. This way:

• Domain models can represent JCR content. That will make it possible to apply features of EMF and other modeling projects to this model.

• JCR node types are mapped to classes.
• JCR childnodes and properties are mapped to EStructuralFeature.

• It will provide a basis for other applications.
• The JCR users will get a JCR Manager tool based on EMF for maintaining a JCR but will also benefit from other projects using EMF e.g. M2M for refactoring the node types using model to model transformations.
• Additionally it can be used in a separate application utilizing the EMF standalone features.

The Current Status

The implemented features do work in my environment. As soon as the integration into ATL or an other EMF consumer works I consider it as a working deep slice and provide a download. This will make the project easier understandable and presentable. After this step I will start focus on building up community.

The Framework

It contains:

• A reusable EMF resource implementation.
• An extendable ecore model. It can be used by extending your domain entities from the JCRMNode entity in this model instead of EObject.
• An extendable and lazy EStore implementation for operations on your model.

What works at the moment

• The mapping between node types and classes works (using annotations)
• The mapping between the node name a property works
• The JCR is loaded using the EMF resource mechanism. (Though plugability still needs to be implemented)

The JCR Manager

A tool that is based on top of the framework to use EMF, modeling projects and other projects to manage JCR content.

What works at the moment

• Currently it displays the JCR content tree
• It's possible to add nodes with a type defined in the domain model
• It's possible to rename nodes
• It's possible to remove nodes
• Undo and redo works at least for the add and rename commands

The Contributions

• My employer inovex GmbH (http://www.inovex.de) contributes 5 person days where I can work on this project within working hours.
• Ed Merks helps as a mentor for questions regarding the Eclipse foundation.
• The ATL team contributed an initial meta model and transformation that will speed up ATL integration.
• Nick Boldt created the initial JCR Management (CVS, website, ...) setup at eclipse.org

To Do

1. Create a small demo of JCRM.
2. Test the EMF features with a standalone version of JCRM.
3. Implement JCRMStoreImpl.move(). The Bugfix 194088 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=194088) that was needed for this method has been implemented, reviewed and released within only two days! While discussing it in the mailing list I always got immediate and good feedback. This is very promising for the future.
4. Wait for the IP review for Apache Jackrabbit 1.3 (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1182) see also http://www.eclipse.org/legal/
5. Understand the Eclipse release engineering to know in which folder structure to check in the initial code.
6. Automatically generate an ecore domain model out of a node type model registered in a JCR.

Done

1. Talk for the Eclipse Summit Europe: It did not got accepted.
2. Tested ATL to use it for node type refactorings. As the ATL team is nice and supporting I would have loved to use their tooling. Additionally to that the model transformation debugger would have been a nice feature. Sadly model modification is not supported at the moment. ATL basically creates new or refined models from a source model.
3. I have a small deep slice now where I can read a model using MWE and modify a model using oAW's Extend language.

Next Milestone

Create a first downloadable presentation of the project to show the potential of Eclipse modeling to the Jackrabbit community.

Values

• simplicity
• transparency
• no dependency on JCR implementations

FAQ

1. What's the relationship between JCR Management and Jackrabbit JCR-OCM?

One part of JCR Management has the same goal as JCR-OCM - exposing node data and operations to domain models - but it uses an MDSD approach based on Eclipse Modeling Framework (EMF). This makes JCRM depending less on reflection and using more generated classes instead. It will delegate as many calls on JCR node data as possible to minimize copying node data to domain model objects. Additionally JCR Management also has many other goals. The source code of JCR-OCM can be found at http://svn.apache.org/viewvc/jackrabbit/trunk/contrib/jackrabbit-jcr-mapping/jcr-mapping/ and the documentation is in the former Graffito project (http://incubator.apache.org/graffito/jcr-mapping/index.html).

CVS Access

Some important things are now checked in. But I still need to find out what exactly needs to be in the CVS and what gets generated and should not be in the CVS. Third party jars are not yet checked in as the IP for Jackrabbit 1.3 needs to be reviewed (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1182).

CVS Repository Connection

• Server: dev.eclipse.org
• Repository Path: /cvsroot/modeling
• User: anonymous
• Password: (leave blank)
• Connection Type: pserver
• Checkout As: Empty EMF Project

Basics Plugin

• Module: org.eclipse.emf/org.eclipse.emf.jcrm/plugins/org.eclipse.emf.jcrm.metamodel

Model Plugin

• Module: org.eclipse.emf/org.eclipse.emf.jcrm/plugins/org.eclipse.emf.jcrm.model