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?
rvt
On
For now we went with Jahia. The reason given is that it looks like the editing portion of websites looks more well though and easer for content editor. I also foubd for myself that it's easer to make new templates, add jQuery and make this work within Jahia.
With Magnolia I kept heaving the feeling I was editing a content repository directly (like editing database tables in pgAdmin) without the 'tree' in Magnolia telling me if what I did was good or not, a lot of guessing was involved. I could fill in invalid values and magnolia would accept that without a problem.
Update on Jahia experience: So far we are very happy with Jahia. At this moment we run it on a single server to around 4000 users without issues. With our current dataset, speed is also not a issue. The support of jahia is pretty good, mucg better then what a other guy posted of weeks, I usually get official support back in 1-2 day(s) (3 days according to the contract) and when I ping some Jahia employed on skype, usually within the hour, they are very friendly folks.
On
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.
On
Here is some feedback on Jahia from a related question I asked on the Apache Roller mailing list:
On
The problem with JCR is that there is not a lot of technical documentation around optimization. A JCR will outperform any RDBMS in most cases. However, it's important to be familiar with the hierarchy structure and know that you should not have more than about 1000 child nodes (so structure your hierarch). I am mastering personalized data for more than 4 million users within a JCR.
Seen from that perspective Magnolia has the better setup, because everything is built within a JCR. Magnolia runs as a Web app instance and is simple to deploy content from one instance to another. Magnolia is what we call a "content centric" CMS. This means that content is edited directly on the page and directly there, where it will appear. Of course it's possible to create so called "lookup content", content, that is created in one place outside of the Web hierarchy, but re-used in multiple places of the Web site (aka "soft referenced content").
Jahia is definitely a very interesting solution, but having to rely on an RDBMS (and hence an unnecessary integration dependency) is a big "con" for Enterprise solutions. Scaling is also not easy, while with Magnolia I can setup a new "publish" (or "rendering") instance any given time, increasing performance and security (fail-safe).
On
Jahia pros:
Jahia cons:
On
We choosed jahia over Magnolia.
cons: - community seems very small - not so much online documentation, forum not super active - requires training to get started
Last year, we had to make this choice ourselves. We installed both Jahia and Magnolia, and after a comprehensive comparison, we went with Magnolia. Although both are similar, it was easier for the developers that make modules in Magnolia than in Jahia. In Magnolia, customization is done via editing jsp templates. In Jahia, it's more complex, in that developers have to create backing java class, then get that class compiled and deployed, and so on.
After we picked Magnolia, we have been quite pleased with the ease of use for content editors, and with the performance (Magnolia will pre gzip up pages and store them in cache for performance.) You can see the resulting site here: www.franchiseprocess.com. Everything you see is based on magnolia templates that the content editors can and do modify.