A Use Case for JCR

A creepy thing, this JCR stuff. Once into your head, you start to see possibilities. And the alternatives (good ol'e RDBMs, for example) start to look... bleak ... boring ... so 2004 ...

Imagine you are in responsibility of a, say, control system, with which different applications having impact on the books of your company have to answer to a catalogue of risk control questions.

So you are responsible for the move from excel sheet to web application. Ok, so you start designing your domain model, all easy, all smooth. But wait: those controls have got the tendency to change, but the respective application owner have to answer to a certain version of your control catalogue. Additional feedback for proposed changes to the controls have to be kept in a separate branch of your risk catalogue, which then will be merged with the trunk of your catalogue.

You see where it is going. This describes only one aspect of the JCR API, which simply is included. Of course you could implement it by using another repository product (e.g. svn), but this is not the point. The point is that the need for a content repository is inherent to several reappearing use cases for software systems design.