JSR-170, the Java Content Repository API, has been released. JCR specifies "content services" such as: author based versioning, full textual searching, fine grained access control, content categorization and content event monitoring. As such, this could be how enterprise applications are recommended to manage raw content.

There are a number of implementations of JSR-170, including Magnolia, Apache Jackrabbit (still in incubation), and CRX.

There is also the eXo Platform implementation.

An RC2 is on the way.

http://forge.objectweb.org/projects/exoplatform

Magnolia doesn't have its own implementation of JSR-170.

Oh, and congratulations to the JSR-170 spec team, of course! :)

Anyone going to see David Nuescheler talk here perhaps?

http://www.cmforum.dk/2005/

Just to let you know, Magnolia is using Jackrabbit underneath.

...and correcting myself: Jackrabbit AND what seems to be a commercial implementation of JSR 170: "Magnolia Power Pack". See their version 2.1 rc1 release just annonced.

How bout settling for "Magnolia uses JCR" :)

I don't think they are using any functions outside the spec, so it should be pretty easy to set up with eXo's implementation. And it's no secret that Magnolia Power Pack uses the CRX repository.

Conclusion: There are so far only three implementations of JSR-170: Jackrabbit, CRX and eXo's persistence layer.

"*only* three" is maybe giving the wrong connotation. There are *already* three implementations, given the fact that the standard has been finalized last Friday ;-)

It would appear that SDO [Service Data Objects] and JCR have very similar notions of data abstraction but differ in their intent. One is designed to unify content manipulation at an enterprise level while the other is designed to unify data manipulation at a programmatic level.

However in what context would you consider using one or the other?

Does anyone have any good resources (online or in print) for a developer's perspective of designing applications for content repositories. I'm specifically interested in using JCR to back a business application.

After reading the JSR-170 specification (excellently written, BTW), I have also read some of day.com's publications. I'm specifically interested in finding out about the following:

- Best practices for designing schemas for business objects
- JCR properties can have a reference to other JCR nodes, but are there techniques for integrating relationships to non-JCR persistent objects?
- Will JCR implementations tie into standard JTA? (May be more of an implementation-specific detail)
- How do you access versioned JCR content? For example, versioning will occur automatically for changes to mixin:versioned nodes, but how would you query these versioned instances. (I believe the jcr:UUID properties are the same for versioned nodes.)
- Is versioned content nodes compatible between different JCR implementations. For example, can you export the repository in XML format from JCR implementation 'A', and import it to implementation 'B', and maintain full content including versioned data?

Content repositories have been around for many, many years. I guess I'm just looking for some good resources (from a programmers perspective) on how to build "non-blog" type applications with them.

Having played with Documentum and knowing how shitty their API is (and its underlying, 100% JNI implementation), I am curious to see when they are going to support this JSR - I guess they will since they were in the expert committee. If so, we could finally start doing real programming on documentum projects.

Not only Documentum, its a case with all the biggies - Vignette, Documentum, Fatwire etc. Most of these players use their own properietory repositories and it will not be trivial for them to make themselves JSR 170 compliant.

On the other hand, JSR 170 will not catch up unless this big guys make themselves compliant. Chicken and Egg??

/a
http://apoorv.info

Not only Documentum, its a case with all the biggies - Vignette, Documentum, Fatwire etc. Most of these players use their own properietory repositories and it will not be trivial for them to make themselves JSR 170 compliant.

Well, this is specifically why JSR-170 is split into Levels. Making any legacy repository JCR Level-1 compliant should not be a very big effort. Actually it is even something that a customer or a system integrator (in a worst case scenario) can do themselves in a matter of a number of hours (or possibly a couple of days) leveraging source code from the Reference Implementation at

http://incubator.apache.org/jackrabbit

On the other hand, JSR 170 will not catch up unless this big guys make themselves compliant. Chicken and Egg?

I think that there are going to be "JSR-170 Connector Vendors" to operate as catalysts for adoption.
My favorite historical example with regards to this discussion is always the "JDBC example". It took the big RDBMS vendors years to come up with their own JDBC drivers and in the meantime specialized "third party driver vendors" provided the JDBC drivers.

Additionally, numerous of the "big" vendors support JSR-170 publicly.
See for example here:
http://uk.biz.yahoo.com/050517/183/fiz2n.html

I completely agree with your observations. However, my fear is that all these big vendors will support JSR-170 so as to get "tick marks" by analysts. However, in order to take advantages of their features, one will need to bypass JSR-170 and use vendor specific extensions. Case in point is JSR168. Many vendors support it but to take advantage of vendor specific productivity tools, you have to use properietory tools. For example BEA portal server provides something called page flows which let you create sophisticated portlets in a matter of minutes using BEA workshop. But if you have to take advantage of it, you cannot use JSR168 portlets.

I would love if my fears are proven wrong though :)

David: As a spec lead of JSR170, you obviously have more knowledge of how many differnt vendors will be JSR170 compliant and hence my observations in the above posgt could be totally wrong.

BTW, JSR170 is certainly a step in the right direction. Many good wishes and keep up the good work. I think with so many M&A's happeing in the CMS industry, this spec could be even more useful, if it catches up.

/a
http://apoorv.info