This post is a overview of some of the architectural problems I have found with Adobe CQ. As a developer with about 15 years of experience and a year and a half working directly with the product I feel I can give some insight in this regard. The following sections deal with key problem areas in turn.
What’s In A Name?
This CMS has undergone a few name changes but none as confusing as currently. Initially called Comuniqué, it rose to prominence as Day software’s CQ. Then, late in 2010, they were purchased by Adobe. Since that time there appears to be confusion from the new owners as to what to call it. CQ 5.4 persists alongside something called WEM (easily confused with ADEP which is apparently the new name for CRX). Nevertheless, at the time of writing, the next beta version of the software is titled CQ 5.5. The real story group have also pointed to this lack of focus. See the following post for more details.
Not All Its Stacked Up To Be
So the merger is a bit bumpy, but what about the underlying technology? Well, about 2005, programmers started to get fed up with the J2EE stack (and Java in general) that CQ is built upon. They started turning to less complicated alternatives like python, ruby and PHP. Bruce Tate, formerly a Java mavin, documents this pretty well in his book of that time: Beyond Java.
Don’t get me wrong, Java is a fine language. I have worked with it for many years now and retain a fondness for it. However, the direction that Sun took Java as a web application platform became overly complicated. Just look at the 100s of lines you get in a Java web application error stack trace compared with other environments and you start to see what I mean.
You Ain’t Got a Thing, If You Ain’t Got That Sling
Well, at least its built on something open-source and freely available. Right? Isn’t it using that apache project Sling and Jackrabbit? Yes, that’s true. But who else is using those projects? It is commendable that Day (and now Adobe) release a portion of their code to the world but the criticism of over-complexity is valid here as well. If Sling and Jackrabbit were widely used platforms, they wouldn’t feel so obscure and undocumented to work with.
Furthermore, there exists a strange gap between the open-source side of the product and the propriety modules built upon them. This feels like the gap that exists between the corporate giant of Adobe and its new acquisition. One hand seems to be uncertain as to what the other is doing. For examples of this disconnect, I direct you to other posts on this site.
An example that I often find of CQ’s complexity is how you will find an example of how something works (submitting a form for example: shockingly complicated in CQ) and you will try this out only to find that it works fine on the author server but runs into problems when on the publisher. Or you figure out the whole author-publisher tangle and run into a brick wall with the dispatcher cache.
This is another example of how the system has so many moving parts that it seems no-one in the organization is sure how it all hangs together. This is particularly noticeable in the weakness of certain non-core modules: social collab, mobilie, etc. Yes, the author interface for CQ is nice to use and it is a key selling point for the software but once you stray from this functionality, the offering gets very weak.
Another frustration for developers within CQ is the inadequate development environment. I have not used the stand-alone eclipse-based CRXDE in a while because of its memory leaks and instability. I mostly focus on the browser-based CRXDE lite. It more or less works although it has its foibles. Neither option, however, provides proper source code management. For that you have to turn to something called FileVault which gives you file based access. It is a complex and brittle process to keep this in sync with a subversion repository.
This kind of duplication of effort is endemic in CQ. There is never a single place to do things but multiple locations that are slightly different. For example, there are two package managers for packaging code. There are multiple ways to browse and edit the repository tree. I can’t remember how many places you have to set the admin password, but it should not be more than one.
The point of all this is to put a record out there of the challenges developers face within CQ. The hope is that Adobe address these problems. Developing within a CMS platform is difficult. If the vendor of the platform listened to our pains then we really could have CRX delight.