How Shotoku compares and contrasts to JCR
NOTE: Shotoku and JCR are two completely different things. This is really a contrast between JCR and Shotoku. Shotoku can provide access to a JCR, or other types of repositories.
Here is a short list of main differences:
The JCR API is much larger than Shotoku providing many more (and different) pieces of functionality than Shotoku.
Shotoku's primary repository implementation is SVN and those repositories are accessible via WebDAV, there is also a possibility to mount a directory as a local disk, or check it out as a working copy. The JCR does not specify the transport mechanism to communicate with the repository but is an API and is designed to be a specification to interact with any repository where it is up to each implementation to define their method of communication (See jsr170-0.12 page 44: JCR on top of WebDAV)
Shotoku is designed to support clustering. JCR doesn't discuss clustering at all.
Dependency injection via annotations - using JBoss AOP. The JCR does not concern itself at all with AOP concepts.
One of the biggest differences, and a distinct advantage of JCR, is the search mechanism - by executing queries. This isn't yet well planned in Shotoku, but we want to use SemanticWeb constructs to enhance the search capabilities.
Another advantage the JCR cms implementations often have, is a web-based interface, through which files can be edited, uploaded, deleted etc. Shotoku doesn't have it, yet (!). It's on our road map :).
What also has to be said, is that Shotoku can use JCR as its content repository.
Finally, here is a short list of things that cause (or rather: will cause) Shotoku not to be a CMS only:
web components - blog and feeds. The latter can be already seen working on this site.
normally CMSs are used only for storing web pages that are shown to the user; Shotoku can be used (and is used in Labs) to store all site configuration: xml-s, navigation menu layout, jsp pages, etc.
it will also have event mechanisms informing about directories/ node changes. This can simplify a lot writing applications configurable via Shotoku.