Great responses..thanks very much for all of them. I think I probably did a poor job of using the term JCR adapter though as I was really referring to just the new Oracle JCR.

The “square-peg” analogy has to do with UCM’s repository vs the JCR XML-based one. From what I’ve heard there is some additional “overhead” with the integration.

Also I was looking for customers using Oracle’s JCR adapter.

All that said, I’ve really enjoyed all the feedback this thread has generated and am working on a Sling example with UCM now. So expect a follow up post soon.

Thanks

David

Re: your question “Is anyone out there using the JCR yet?”. You might want to have a look at the post JCR Standardization and Consolidation by the JCR specification lead, Day’s David Nuescheler. It shows, with two nice slides, a sample from the large pool of both JCR-enabled repositories and JCR-enabled applications, which are on the market today (Kyle’s mention of the KinnosaONE above is yet another example .

Oracle themselves have settled on using JCR standard as the cornerstone of content integration for their enterprise infrastructure, applications, and development tools. The following products from Oracle’s suite have JCR support as of today:

* WebCenter, a major part of the new Oracle 11g suite, is going to have JCR-based content integration (see WebCenter roadmap presentation, Content Integration, slide #14).

* The foundation of the content ingegration, JCR-enabled ADF application framework, has been available for some time in Oracle 10g JDeveloper and Oracle Application server.

* Other known Oracle application products supporting JCR integration (JCR-enabled) are Oracle Portal (see, e.g., this blog) and BEA (now Oracle) WebLogic Portal (via WebLogic JSR 170 Adapter). The list might surely be longer.

* JCR-enabled content repository products, integrating with Oracle’s stack are their own UCM and Oracle ContentDB, as well as EMC Documentum, MS Sharepoint, and IBM Lotus Domino/Notes through additional JCR adapters for these products (see the aforementioned WebCenter roadmap slide).

Re: “JCR wrapper from a high level is a lot like a square-peg-to-round-hole connector”. If one looks at it from the (content) integration perspective, though, it makes a lot of sense as it greatly simplifies integration between various applications and content repositories / providers, and also allows the development tool vendor create fairly generic components working with a variety of content sources (e.g., ADF components from Oracle). Ultimately, it leads to a pluggable architecture, and gives customers more freedom in deploying stuff and reusing/leveraging their existing investments, while working with the new technologies.

Note also that by adding a JCR adapter, UCM’s features can still be leveraged through native user interfaces and APIs, and in addition to that all the applications running on top of WebCenter, ADF, or JCR, can leverage the content managed by UCM without extra effort or cost. The fact that “a number of nice ADF components [...] “just work” with UCM” seems to have been enabled by the JCR standard used in both products.

Both our document management products, Korrigo and Kinnosa, utilize the same JCR (java content repository) for storing and managing critical engineering documents, such as CAD files. Our heritage is in the engineering content management arena where we specialize in providing the highly advanced document management functionality that engineers require to manage complex CAD files, file relationships, and collaborative design processes. We have extended the JSR-170 spec farther than any other software vendor in the Engineering community to create service-oriented architecture (SOA) solutions for engineers. By using a JCR to store and manage files (we call our content repository the Kinnosa JCR) we can provide an open, yet secure, repository for storing files. The JCR has allowed us to challenge the traditional paradigm that documents must be housed in locked, proprietary data vaults. We have developed Add-Ins to the CAD tools our customers use for design work as well as with Microsoft Office, Windows Explorer, and OpenOffice desktop applications. The open Kinnosa JCR can be accessed by these CAD tools, Windows Explorer and common desktop applications so that documents can be managed from the user’s preferred interface.

The JCR approach has really created our opportunity in the Engineering Document Management market. The Kinnosa JCR allows our customers to connect their engineering document repositories with more enterprise-oriented content management (ECM) systems like Documentum, SharePoint, Lotus Notes and others by using connectors, like those described in your posts. Our customers essentially create a “virtual repository” that unifies their data and existing vaults and repositories. Document repositories can be located in different departments, offices or countries but can appear to be all stored locally.

The JCR has allowed us to provide our customers with a truly distributed environment where files can be managed in real-time, without having to resort to inadequate methods such as data replication or data duplication to facilitate collaboration. Additionally, the JCR and virtual repository unifies disparate systems into a single consistent view which eliminates the need to consolidate systems into a centralized corporate repository or conduct painful data migrations projects.

For any of your readers looking to learn more about how we’ve used the JSR-170 spec, here are some hyperlinks to our Website:

First Trace Homepage: http://www.FirstTrace.com

This link provides an overview of our KinnosaONE product family: http://www.firsttrace.com/product-kinnosa-one.jsp

This link provides some information about our software architecture and how we’ve utilized the JSR-170 spec: http://www.firsttrace.com/product-kinnosa-one-architect.jsp

Thanks for the update, tho. I have a client who wants to explore this, so I’ll let you know if I discover anything noteworthy.