I believe that this JSR is trying to over simplify the needs of a CMS API. Maybe similar to other vendor specific JSR's like JSR 143 and its oversimplification of write once run everywhere fully manageable fat clients. There is a lot more to a good CMS vendor's API than just versioning and locking checks. An API really needs the vendors value offering incorporated into its own API; because we all know each product has different value propositions. However, perhaps more important is the real value to us the users and implementers of these CMS's. I would purpose a more finely tuned requirement for a CMS JSR.
What I would like to see out of a CMS JSR is a nice clean java API that interfaces with any type of content repository. This API should allow users access to production available content. Both, Weblogic and Websphere have this concept built into their personalization API's, I am more familiar with Weblogic's. Weblogic has a document service providers interface, the "Document manager." This API allows me, a weblogic developer, to request content from a content repository, through a vendor neutral interface and vendor neutral query language. Many of the vendors, IWOV, Fatwire, Documentum, Stellant, etc... have built a "Document manager" for BEA's personalization product. Now what I believe would be nice is if, on the coat tails of JSR 168's success, the vendors could produce one driver, i.e. similar to JDBC, to interact with production capable content from their blackbox content repositories (regardless of the products native language). In essence, providing developers with the ability to create a write one query to execute against any type of content repository. This interface shouldn't just be limited to CMS vendors but also other software markets as well, such as querying into ecommerce product catalogs and trouble ticketing systems knowledge bases.
The subsequent architecture to this JSR would be the framework to "plug" these drivers together so that developers could execute one query and receive a consolidated result set from all content repositories. In essance creating the holy grail of an enterprise content bridge. I think that this would provide much value back to all of our customers and not just Communiqué's customers.
There are many opensource CMS product downloadable on the Internet. However there are only a few java based downloads. In this article, I will reference a few of the products and as time passes, I will try to write a quick review on them as well.
The old ARS Digita product now sponsored by Redhat and calledCCM
OpenCMS but be careful with this one. for a while all their documentation was in German ;-).
Cofax which is a neat little CMS, mainly for a heavy publishing site
MMBase
Leyna from Apache
An unorganized list of links related to CMS'ing.
http://www.ecmag.net/
http://www.cmswatch.com
http://www.gilbane.com/
http://www.metatorial.com/
http://www.contentworld.com/
http://cmsfocus.com/
http://dmoz.org/Computers/Software/Internet/Site_Management/Content_Management/