hands on (+6 months) experience with Magnolia and Jahia, what's better?

Question

we are looking into a java based CMS (yes java, we are moving away from scripting languages).

Anybody has hands on experience with teh community editions of Magnolia and Jahia, what's easer to make modules against and what's your overall experience?

• For the content editors
• For the developers (that make modules)
• How easy it is to handle change request (can you add this or that to page foo/bar)

rvt

Answer 1

Disclaimer: I'm Jahia CTO. I hope this answer will be acceptable by StackOverflow standards, otherwise please let me now and I’ll improve it. I first wanted to answer as a direct comment on the answer but that doesn't seem possible.

I'd just like to address the cons that were listed by GKrost, as some of them are not quite accurate anymore (since this was written there was at least one major version of Jahia released) and others are not correct.

Jahia cons:

JCR seems to be a bottleneck for large (10000+ pages, > 50000 content elements) sites, especially when using mysql. The bundled Java-In-Memory-DB is much faster.

Actually the JCR has nothing to do with this, as it is simply a specification. You are talking about the underlying JCR implementation, in this case Jackrabbit. While it is true that it is hard to beat the performance of an in-memory database such as HSQLDB (http://hsqldb.org), it is also not recommended to use such a database in production as it is not designed for enterprise deployments such as clustering environments. Another reason why it is not recommended is that it will use up precious heap space on the same JVM as the CMS, which will become problematic as the data grows.

As for size limits, 10000+ pages is indeed quite a large site, most installation rarely reach this size, but in case they do there are multiple ways of distributing the data. 10000+ is also a limitation that mostly applied to Jahia 6.5 and older versions of the CMS, but now it is quite possible to go above that. As for the 50000 content elements this limit is not correct. We have deployed installations with much more content, but it is true that content design structure is important to make sure that bottlenecks will not be introduced, but this is true of any CMS out there, or even technologies such as ElasticSearch where sharding must be properly managed to avoid performance issues.

Jahias Lucene version is outdated

Jahia's default Lucene version is actually the one used by the underlying Jackrabbit JCR implementation. As of Jahia 7, which allows to develop OSGi modules, it is possible to embed another version of Lucene or even ElasticSearch inside your own bundle, without interfering with the one required by the JCR backend. This is not possible, to my knowledge, in non-OSGi CMS' such as Magnolia (but possible with Adobe which uses Apache Sling which is an OSGi-based web framework).

when developing own Apps / Modules you'll have to use JSP, you cannot use JSF (Jahia has plans to integrate Spring Webflow, but you never know if and when ...)

Actually you can to use JSP/Groovy/Velocity or whatever language that is supported by the Java Scripting API. Spring Webflow was integrated in Jahia 7, which is now available and all the administration modules are fully developped using Spring WebFlow (http://www.jahiaone.com/home/program/session/MVC-in-Jahia7-Using-SpringWebFlow). As for JSP we provide powerful tag libraries that make it easy to develop views without the need for any scripting, as most of our own views contain no Java code. JSF integration should be possible too, but is not provided out of the box and requires a good understanding of how to integrate JSF into an existing servlet controller.

Support is way to slow when it comes to reaction times

This is simply not true. Our SLAs are very clear and we have always respected them :http://www.jahia.com/services/technical-assistance . Total support times do however also depend on the speed of answer of the customer.

sometimes it takes weeks for a hotfix/patch to critical bugs

This used to be the case 2 years ago, but since then we have put in place a monthly hotfix release system and that is accelerated in the case of security issues.

no ability to export/import historical versions; the only way is to copy things manually from the underlying database

This is indeed by design. Most import/export operations were designed to not deal with versions as they are most often used to migrate a pre-production environment to production, or the opposite. Not that if versions of a content object exist when you import that same object, they will not be erased. It is possible to export versions using the JCR though, but this is not provided out of the box. For backup purposes we recommend to backup at the system level.

Jahia is designed to work as a cluster, but it cannot replicate user sessions. That means, that users have to re-login when the cluster node they are authenticated with, falls down.

This is not true anymore, but used to be. Before Jahia 6.5 our sessions were not serializable, but this is no longer the case. So this is mostly a limitation of the application server configuration which is not configured by default to replicate sessions. In real life this is not (much) of a problem since cluster node failures shouldn't happen and when they do minor limitations are to be expected.

Cluster nodes must share the DB and the filesystem. You cannot cluster the db. Jahia does not support (technically) MySQL Cluster. (Background: they put indices on BLOB/CLOB which is not supported by MySQL Cluster)

I don't think this is correct either. I just double-checked all the indices we set on MySQL and we don't set any of them on BLOBs/TEXTs or any long version of those. Also in most of our cluster deployments clients usually prefer to use Oracle as it is more established for such solutions. Jahia also supports other powerful databases such as PostgreSQL or Microsoft SQL Server that also support clustering.

the general documentation has room for improvement, JavaDoc/Source documentation is basically not existent

I agree with this, documentation can always be improved and we are constantly working on it. Our JavaDocs are available here : http://downloads.jahia.com/downloads/jahia/digitalfactory7.0.0/digital-factory-root-7.0.0.0-javadoc/ and source code documentation is something we work on all the time.

weak community; most of the answers in the jahia forum come from jahia employees.

This however is mostly true, but at the same time a lot of our integrations come from partners who unfortunately don't have the time or the opportunity to participate. This is why Jahia employees answer out of their free time but most questions get answers, which is after all a good thing don’t you think ? We are of course always looking for new ways to expand our community, and our first user conference JahiaOne surpassed our most optimistic forecasts. On the forum I think it would be a good thing to add monthly digests since currently there is no incentive for users to come back.

no public templates (except the ones that from jahia) available

No comment there. We deliver a few default templates that are as generic and complete as possible, but we welcome all contributions.