Java-based CMS with RESTful service / API to access content [closed]

Question

For those who might vote to close this question due to "not constructive - As it currently stands, this question is not a good fit for our Q&A format." - Would be great if you would suggest where should I post this question (https://softwareengineering.stackexchange.com/ ? or any CMS-focused forum?)

Similar questions have been asked before:

• https://stackoverflow.com/questions/918722/java-or-php-for-homegrown-cms
• https://stackoverflow.com/questions/4005811/is-there-a-good-cms-for-java
• https://stackoverflow.com/questions/8298790/java-web-cms-recommendations
• https://stackoverflow.com/questions/4837502/recommendations-for-a-lightweight-java-web-cms
• https://stackoverflow.com/questions/1939238/can-you-recommend-an-easy-to-use-easy-to-develop-cms

All of them are a few years old, so I am wondering if there are new recommendations / discussions around this.

Some background: We are a Java shop, we create / maintain websites for our clients, our tech stack are Java, Spring, SQL, JSP, HTML5, JQuery, Tomcat, JBoss, Maven, etc ... the usual stuff. So far in terms of "content" we either put it in some properties file read in by the JSP for copies (eg. description of product X) or back-end service that provide dynamic content (eg. what's the current value of product X).

Now we are rethinking our approach to managing content because we are managing more and more properties for the client with the same content (eg. a website, mobile website, mobile app, etc), so we definitely want to avoid having multiple copies of the same content spread around.

A few things I am particularly looking for:

1. Java-based (because we are Java shop: 1) more expertise in handling Java-based stuff and 2) avoid introducing another tech to the stack)

2. Extensibility / customization. Need to be able to customize the CMS (which is why we want to stick within our Java expertise) so that it can be extended to connect with other web services to consume content, etc.

3. Focus on content - we need clear separation between content vs UI-render, going back to what we are looking for where we will need to deliver the content into separate properties.

4. RESTful service / API to access the content - same as above. We need the content to be accessible directly as a JSON / JSON-P /. XML feed.

5. Need to have a decent UI to work with and the more intuitive the better for business user because some of our client that might be moved to the platform will likely want to be manage their own content

6. Multilingual support

7. Open source / low cost

So far, several options that I have are:

Adobe CQ - Looks to be the most ideal solution, but unfortunately it's cost prohibitive

Hippo CMS - Looks to fit what we are looking for, I am unsure of how well it's documented, tutorial / how-tos seems to be quite sparse, their market share seems to be bigger in Europe than in North America.

Liferay - More focused as "portal" as opposed to CMS providing content

Alfresco - More focused on "documents"

dotCMS - Like Hippo CMS, seems like this one might fit our needs.

Magnolia CMS - Looks around the same alley as dotCMS and Hippo as well. From the comments I've seen seems like they are more focused on a single website and not clean separation between content vs UI.

I personally don't have much direct experience working with CMS before.

Your thoughts / comments on each of the options above, or if you have other solutions in mind not mentioned here, would be greatly appreciated! One of my challenge is that we need to make a really sound decision because whichever path we decide to go down with, we would likely be stuck with it, decision is not something that can easily be discarded and start over.

Answer 1

Personally I have some experience with Hippo and a lot with dotCMS. I do know a little about Alfresco, Liferay and Magnolia but I have not worked with them before. I have no experience whatsoever with Adobe CQ, because I never took the time investigating. This is because of the high costs being a no go for many of our clients. Alfresco is indeed a better solution if you're looking for an online document management system, which I think you aren't. You are right about Hippo, Magnolia and dotCMS being somewhat similar, which isn't that strange because they try to solve the same problem: being an Enterprise class Java based Web Content Management System. They focus heavily on managing the content which can be used in pages that are also manageable with the CMS.

To be honest: I have a bias towards dotCMS because I have worked with the systems a lot and know much about it. I thought I'd explain why it works for us so you can take that into consideration. I work in a Java shop that does a lot of middleware development for its clients using JBoss and the whole EE stack. We connect old (Cobol) and new systems together and put a shiny new web interface on top of that middleware that targets both admins and consumers. To be able to create these interfaces we need a CMS that does a few things well:

1. Java based (because we're a Java shop this enables us to have the same people work on the CMS and the middleware)
2. Horizontal scalable to tens of servers without too much hassle. In the classic case when scaling out to multiple servers the database and the assets folder are shared between the nodes. This could be a problem when you have many nodes, but in practice it's not such a big issue because most of the load will hit the index and not the db or the disk. In 2.5 and up dotCMS offers a "share nothing" mode where each node has its own database and assets folder, but this does requires you to use an additional (read: licensed) authoring server that pushes the content to each of the nodes. I have not played with this setup myself, but it sounds promising, especially because each node can be a simple and cheap box that only uses postgresql / mysql and tomcat and because there is no single point of failure anymore. In the classic case if the shared assets folder or the db would die all nodes would be down as well, except when you cluster the db and the disk as well which is expensicv to do. With this "share nothing" setup this is no longer the case. As I said: I have no experience with this, but it sounds like it might work.
3. Admin interface usable by both power users and non techie people (clients). Not everybody is "good with computers", but they too need to be able to manage the content (very often these people work in the marketing department of our clients). dotCMS offers ways to create admin interfaces that show only a few of the functionalities dotCMS offers. This prevents them for having to understand the whole system which speeds up training and acceptance.
4. Structured content. This is biggie. We want to be able to define many types of content all with a fixed set of fields, just like a database table. All without having to rebuild or restart the system. The people that would define content based on this structure (the name dotCMS uses for these types) cannot enter invalid data because the system protects against that. This makes building websites so much more future proof and convenient. Especially for developers.
5. Focus on content first. The first months that we used dotCMS we actually only used dotCMS for managing the content itself and exposing that through JSON API's. We did not use CMS features like defining templates and creating pages. This works fine and sounds like the stuff you're looking for. dotCMS has a JSON/XML Webservice that returns content based on queries. We use this a lot in almost all our projects, see here for more info: http://dotcms.com/docs/latest/ContentAPI. Using dotCMS itself for the whole frontend is also a possibility. Especially with the Spring controllers that it supports and the CSS-framework agnostic new template designer it is a nice way to build systems that require more than just some content.
6. Multilingual. dotCMS offers a few ways to do this. You can create content in all languages that you need, even non textual content such as images. Because of the "content first" approach many things are content in dotCMS , and can be treated as such, including creating a version for each language that you need.
7. Open source. dotCMS offers a community version that we use most of the time. Only for the pro features like load balancing, using oracle for the database, etc, a paid version is necessary. And even then the costs are manageable. See http://dotcms.com/products/editions/ for more details about this.
8. Internal caching mechanism. Because of the high load some of the sites we have build need caching. DotCMS uses the Google Guava for their caching which works pretty well.
9. Extendability, also a biggie. We needed to be able to extend the functionality of dotCMS for obvious reasons. DotCMS used to only offer an old school way of doing plugins that is kinda ugly and is based on an ant script that overwrites the dotCMS classes with your own. It works fine, but I always feel dirty after writing such a plugin. However since version 2 they offer an OSGi based plugin framework that is pretty sweet and much more developer friendly. It went out of beta in the 2.5 version. We're planning to port all of our plugins to the new framework.
10. Multi host. We need to be able to host multiple sites within the same CMS. DotCMS provides this natively. It's also a nice way to share common stuff between multiple hosts which we use a lot.

Of course there are also down sides. Here are a few:

1. Web CMSes like dotCMS store its content in a database and the assets as files on the disk. This makes versioning and synchronizing between different servers a pain in the butt. Starting from the 2.5 version dotCMS offers synchronizing tools that enable you to push content from one environment (for instance UAT) to another (for instance PROD), which helps. But not being able to checkout a single version of the content from something like GIT or SVN is very annoying. Especially since we as Java developers are accustomed to things like automated testing in a continues integration environment. Of course you can store the database as a SQL statement and the assets directory but that's slow and not so "nice". But then again all systems that store state in a database have this flaw.
2. DotCMS takes some time to learn. It's not a small CMS like Wordpress that you'll understand in one afternoon. It has many features and is very powerful, but you'll most likely need a day or so to understand the dotCMS way and then another couple of days to understand all the API's. I do encourage you to first read some docs and tinker with it before building a real production site: many ways lead to Rome, but some of them consist out of quicksand. :)
3. DotCMS is RAM hungry. To keep things fast it cached everything, so if you have a lot of content it will eat away at the RAM you have available. You can tweak this but it's easier to just give it enough RAM we have found.
4. Not all configurations of WebDAV + editing client are compatible with dotCMS. For instance on a mac I have found that you best use Cyberduck as a WebDAV client and Aptana as a text editor. Other setups do freaky things that dotCMS does not like much. You got to play a little to find out what the best setup is for you. I did find that if you file a bug on their github they get it fixed in the next release. They told me that WebDAV is hard to get right because it's not a fixed standard which I understand but it can still be a pain in the butt.

If you want to learn dotCMS read their -not so bad- documentation: http://dotcms.com/docs/latest/TableOfContents and also take a look at their demo site (http://dotcms.com/products/demo/). In the demo site you'll find examples of all the concepts that dotCMS offers. Oh and check out our own free dotCMS plugins as well. Especially the JavaScript and CSS minifier is very handy: http://geekyplugins.com/.

Hope this helps a little. Let me know if you want to know more.

Answer 2

Disclaimer: I work for Hippo, so I'll try to only answer with facts and not opinion :-)

1. Hippo is fully Java based, front end is language independent, but geared towards JSP or Freemarker, optionally you can use a REST-interface and use whatever.

2. Many plugins are created and collected at the Hippo forge.

3. Content-centric design has been a staple of Hippo development, should pose no issue.

4. Yes, by default all JCR calls are available. Apart from that you are able to define your own REST interface to suit your needs, example in the demo, documented here.

5. I dare say yes, in my experience most non-tech users find the interface easy to understand.

6. Multilingual is easy, part of the default multi-channel setup.

7. The community edition (which is complete, no bait-and-switch) is open source, there is some enterprise functionality behind a proprietary license. The license also opens up support avenues, besides the Google Group and Stack Overflow.

Now, on your comment about the documentation being incomplete, let me offer my opinion: You are right, the documentation is an ongoing struggle. Most stuff is documented, but is hard to find. We are working on improving the overviews, introductions and tutorials, but we are obviously not done yet. If you can't find anything, usually the community is able to help and point you in the right direction.