基于Java的CMS，使用RESTful服务/API访问内容

对于那些可能因为“不具建设性——就目前而言，这个问题不适合我们的问答形式”而投票结束这个问题的人来说，如果你能建议我应该在哪里发布这个问题（？或任何以CMS为重点的论坛？）

以前也曾提出过类似的问题：

他们都有几年的历史了，所以我想知道是否有新的建议/讨论

一些背景：我们是一家Java商店，我们为客户创建/维护网站，我们的技术堆栈是Java、Spring、SQL、JSP、HTML5、JQuery、Tomcat、JBoss、Maven等。。。通常的东西。到目前为止，就“内容”而言，我们要么将其放在JSP读入的一些属性文件中以获取副本（例如，产品X的描述），要么放在提供动态内容的后端服务中（例如，产品X的当前值是多少）

现在，我们正在重新考虑管理内容的方法，因为我们正在为具有相同内容的客户管理越来越多的属性（例如网站、移动网站、移动应用程序等），因此我们肯定希望避免将相同内容的多个副本传播

我特别想要的是：

基于Java（因为我们是Java商店：1）在处理基于Java的东西方面有更多的专业知识，2）避免在堆栈中引入其他技术）

可扩展性/定制。需要能够定制CMS（这就是为什么我们希望坚持我们的Java专业知识），以便它可以扩展到与其他web服务连接以使用内容等

专注于内容-我们需要在内容与UI呈现之间进行清晰的分离，回到我们所寻找的内容，我们需要将内容交付到单独的属性中

访问内容的RESTful服务/API-同上。我们需要以JSON/JSON-P/的形式直接访问内容。XML提要

需要有一个良好的用户界面来使用，而且对业务用户来说，界面越直观越好，因为我们的一些可能被移动到平台的客户可能希望管理自己的内容

多语言支持

开源/低成本

到目前为止，我有几个选择：

Adobe CQ-看起来是最理想的解决方案，但不幸的是，它的成本过高

Hippo CMS-看起来符合我们的需求，我不确定它的文档记录得有多好，教程/指南似乎非常稀少，它们在欧洲的市场份额似乎比北美更大

Liferay-与提供内容的CMS相比，更侧重于“门户”

露天-更关注“文档”

dotCMS-就像河马CMS一样，这一款可能适合我们的需要

木兰CMS-看起来与dotCMS和河马一样。从我看到的评论来看，他们似乎更专注于一个网站，而不是将内容和用户界面完全分开

我个人以前在CMS方面没有太多的直接经验

---

如果您对以上每个选项的想法/意见，或者您有其他未在此处提及的解决方案，我们将不胜感激！我面临的一个挑战是，我们需要做出一个真正正确的决定，因为无论我们决定走哪条路，我们都可能会被卡住，这个决定不是一件可以轻易放弃并重新开始的事情。

就我个人而言，我对河马有一些经验，对dotCMS也有很多经验。我确实对Alfresco、Liferay和Magnolia了解一些，但我以前从未与他们合作过。我对Adobe CQ没有任何经验，因为我从未花时间调查。这是因为对于我们的许多客户来说，高昂的成本是不可能的。如果您正在寻找一个在线文档管理系统，那么Alfresco确实是一个更好的解决方案，我认为您没有。Hippo、Magnolia和dotCMS有点相似，这并不奇怪，因为它们试图解决相同的问题：作为一个基于Java的企业级Web内容管理系统。他们非常注重管理内容，这些内容可以在CMS也可以管理的页面中使用

老实说：我对dotCMS有偏见，因为我与系统打过很多交道，对它了解很多。我想我应该解释一下为什么它对我们有效，这样你就可以考虑到这一点。我在一家Java商店工作，该商店使用JBoss和整个EE堆栈为客户机进行大量中间件开发。我们将旧的（Cobol）系统和新的系统连接在一起，并在中间件之上放置一个闪亮的新web界面，该中间件同时面向管理员和消费者。为了能够创建这些接口，我们需要一个CMS，它可以很好地完成以下几项工作：

基于Java（因为我们是一家Java商店，这使我们能够让相同的人在CMS和中间件上工作）

横向可扩展到数十台服务器，无需太多麻烦。在典型情况下，当扩展到多个服务器时，数据库和资产文件夹在节点之间共享。当您有许多节点时，这可能是一个问题，但实际上这并不是一个大问题，因为大部分负载将命中索引，而不是db或磁盘。在2.5及以上版本中，dotCMS提供了一种“不共享”模式，其中每个节点都有自己的数据库和资产文件夹，但这确实要求您使用额外的（读：许可）创作服务器，将内容推送到每个节点。我自己还没有玩过这种设置，但它听起来很有希望，特别是因为每个节点都可以是一个简单而便宜的盒子，只使用postgresql/mysql和tomcat，而且不再存在单点故障。在典型情况下，如果共享资产文件夹