This release candidate contains all the mandatory features required by the specification for level 1 and level 2 JCR implementation, and includes several optional and implementation-specific features such as:

The distribution contains a WAR file and all the libraries needed to run the JCR in a servlet environment as well as standalone. The implementation back end is made on top of any popular database such as Oracle, MySQL, or DB2. (HSQLDB is embedded by default).

The implementation back end is made on top of any popular database such as Oracle, MySQL, DB2...(hsqldb is embeded by default).

This implementation is based on the current final draft of JSR-170, and will go final after adding the optional features of JSR-170 and passing the compatibility tests.

interesting work, it's good to get a db-backed implementation because the jack-rabbit (JR) implementation doesn't strike me a very sensible solution. a db implementation would make magnolia a more viable option as a cms, i don't think it is currently because of the weakness of JR.

This implementation has been distributed as a standalone product but is also included in the whole eXo Portal and CMS product.

Actually it is bundled in the eXo Platform 1.1 (currently in development but the src are available on the ObjectWeb subversion site) and will provide the basis for our new CMS product (integrated in the portal). Stay tuned...

interesting work, it's good to get a db-backed implementation because the jack-rabbit (JR) implementation doesn't strike me a very sensible solution. a db implementation would make magnolia a more viable option as a cms, i don't think it is currently because of the weakness of JR.

Jackrabbit does have a hibernate persistance manager (the orm-persistence contrib). It might not be top-notch at the moment though (the author is buzy with some other stuff).

So what will be the main differences between this eXo JCR and Jackrabbit? The license?

So what will be the main differences between this eXo JCR and Jackrabbit? The license?

Our implementation is based on our IoC service architecture and leverages some of the existing service of the eXo platform such as:* the indexing service (based on lucene search engine) that is mount on top of the specification, * the organization service (which allows a simple swap from database store for the users or an LDAP implementation), * the security service (JAAS management when embeded in an application server), * the remote service (for the clusterable cache),* the backup service (for backup of the organization model, aka users and groups)...

The license is also not the same as we are GPL and our company (eXo Platform SARL) will provide a dual license for ISV and OEM as well as service and support.

Finally, as a comment I would say that the more implementation we have (Open Source or not) the faster the specification will be adopted. Competition is always good if it is a fair one and in that case it is the case (I wish all our competitors were as nice guys as David Nuescheler (Spec Lead, Day Software, Inc.) is.

We Magnolians for one are happy to have another player on the field - thats what standards are all about. Not only will it be possible to use the exo-jcr implementation as an alternative to Jackrabbit (Apache) and Magnolia Power Pack (proprietary + support + maintainance), but also it should be straightforward to access content of other systems (in that case, access Magnolia content from exo and vise versa) easily.

i appreciate all the effort that you guys put into making this happen.i would also like to hear what application vendors sayabout compatibility between the exo repository and jackrabbit. i think we could even make sure thatthe two are compatible beyond the spec (let's sayaround things like access control, nodetype creationetc..)

To me it makes no sense to offer an jcr-src download which doesn't contain the jcr services and other dependencies. Yes I read the README... And it is just inconvenient to hunt through the code and find out which dependencies you need from the platform. Don't put everything in the platform! Small modules which you can use or not would be better...

Java Content Repositories are mostly used (or to be used) in CMS applications. But I'm wondering whether we could use it for prototyping small applications. It wouldn't probably scale well for big webapps, but it'd be interesting to see if JCR's API could be used as a lightweight persitence framework.

I'm looking forward to play with this promising JCR implementation! Thanks to the eXo team!

Just as a sidenote, the JCR is built on top of the service container kernel which allows you to register Groovy objects in the container.

For example you could implement, in Groovy, a Listener object as defined in the JSR 170 specification (Observation chapter) and send an email to the administrator of the site each time a node is added. Of course as this is written in Groovy you will not need to build if you modify the code (well I know it is a trivial example :-) )

Yes it makes a lot of sense. It is on our TODO list for an upcoming release but the work for that has not started yet and will only when the other functionnalities of the spec are implemented unless someone wants to contribute :)

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.