Why Use JCR?

Do you know how your website data are stored? Images can be stored in a file system, and metadata are in some dedicated files, for example, in .xml files, and text documents and PDFs are stored in different folders with metadata in another repositories and in a proprietary structure. How do you manage updating these data and access rights? Where and how do you start if your leader asks you to manage different versions of each document? The larger your website is, the more Content Management Systems (CMSs) you need that allows tackling all these issues.

These CMS solutions are provided by different vendors and each vendor provides its own API for interfacing the proprietary content repository. The developers MUST deal with this and need to learn about the vendor-specific API. If you intend to switch to a different vendor in future, everything will be different, for example, you need a new implementation or a new interface.

JCR provides a unique Java interface that allows you to interact with both text and binary data, and to deal with any kind and amount of metadata of your documents. JCR supplies methods for storing, updating, deleting and retrieving your data without being dependent on the fact that the data is stored in a RDBMS, in a file system or as an XML document. The JCR interface is also defined as classes and methods for searching, versioning, access control, locking and observation.

Furthermore, the export and import functionality is specified so that a switch to a different vendor is always possible.

What does eXo JCR do?

eXo JCR fully complies with JSR 170; therefore with eXo JCR you can use a vendor-independent API. It means that you could switch to a different vendor whenever. By using the standard, you can reduce your lifecycle cost and long-term risk.