What the heck is JCR Management? Sandro Böhme Architect, Developer, Project Manager at inovex GmbH, www.inovex.de Component lead of Eclipse JCRM http://www.eclipse.org/modeling/emft/?project=jcrm Contact: sandro.boehme@inovex.de

What is a JCR? JCR = Java Content Repository is a datastore that is compliant to the Java Content Repository standard. It is mainly driven by the content management community.

What is JCR Management? JCR Management or short JCRM uses Java Content Repository implementations as a backend for EMF and provides tooling for maintaining this backend. It in its inception phase. Has already produced some prototypes.

Intention of the talk Explaining the goal of JCRM and the JCR integration into EMF. This way you can influence it in a direction that matters for you.

The goal of JCRM Creating synergies between strong and mature communities: The Eclipse modeling community and the JCR implementation communities.

Advantages for the JCR implementation communities They do not have much tooling for editing the data or the type system notations. Reusing the user interface of the EMF editor for a JCR editor tool. Reusing the class diagram of the Ecore tools component Shows the inheritance and containment structure of the JCR types The JCR specifies a textual type system notation. Using oAW XText it was possible to build a text editor At the moment it provides validation and code completion Editor for a XML type system notation Again using EMF it was possible to configure the ECore model editor to persist the data in this specific XML format. Provides copy/paste, undo/redo, drag/drop out of the box

Advantages for the Eclipse modeling community, part 1 A datastore The main JCRM feature is the JCR backend for EMF. The EMF API can be used. This way: It is easy to use for other EMF based projects. The generated EMF model editor and the standalone API work out of the box with the JCR backend Multi user capability In JCRM a new EMF resource creates a new user session Maturity/Scalability JCRM could successfully create and store about 1.5 million EMF objects at once The three JCR implementation vendors base their commercial product on their implementation

Advantages for the Eclipse modeling community, part 2 Object grained versioning It would be highly non trivial to implement this on my own. Object grained locking The other features are not yet integrated into JCRM Full text search XML Import/Export Observation Transactions

How straight and easy is the JCR integration into EMF?

Data structure mapping The JCR has a graph structure of node objects where every node can have a list of properties. This graph is comparable to a graph of EMF model objects with its properties. Difference: A JCR node directly has a list of child nodes no matter what type it has EMF has a further indirection. I can have a list of containment features. Only there are the child objects JCRM resolves that difference That further indirection sounds more complicated than it really is. In fact it was not hard to implement and its clear which node corresponds to which object.

Type structure mapping The JCR type system is quite similar to the Java type system and thus to the EMF type system. node types --> classes super type --> parent class mixin's --> interfaces properties --> properties String, Date, ... --> String, Date, ...

Type structure mapping / Differences JCR concept of residual nodes. Comparable to an EMF containment feature without a specific name JCRM generates a name for it that is based on the type name of this node. This way it is mappable to the EMF type system without problems. JCR concept of value contraints e.g. min 5 pages for a book list of valid strings in a string property

JCR Integration into EMF

EMF model

JCR data structure

JCRM model

JCRM model JCRM combines these two data structures. Each EMF object contains the corresponding JCR node. This has two major advantages. First: No copy of the data needed. It works by delegation. Second: lock(), checkout(),... can be simply delegated to the node.

JCRM runtime implementation How can JCRM make sure that every EMF object has a node and how does the delegation work? Hooks of the EMF EStore get()/set() delegation Attaching the node ... The delegation needs the concrete type mapping. This is specified in the ECore annotations that JCRM generates.

Summary The communities benefit from each other. A quite straight JCR integration to EMF is possible. Easy use in existing EMF applications. Do you have any questions? What do you like or dislike about it? I'm looking forward to your feedback! You can reach me by email or of course personally here at the conference if there is interest, I can organize a BOF about JCRM