To Go or Not To Go with Liferay? What's the good, bad, and ugly?

Question

We are evaluating several solutions for a new web thing we're looking to build. There are several aspects to it, including user management, content management, campaigns, community, and financial transactions.

We are looking to roll the framework ourselves, using Joomla + Vaadin + CAS (to name a few) to DIY, but I am wondering if we should simply adopt the Liferay portal for one-stop shopping?

I have looked for testimonials and have not come up with much. I appreciate anyone who has used Liferay (or chosen not to) who would share what technical hurdles it solves (or doesn't) and potentially what others it may create.

Thank you!

Solution 1

We decided not to go with Liferay primarily because we did not need a portal server and would only have been using it for security things. Since we were running against an Active Directory server for maintaining user info and permissions, we decided to just build out a Spring MVC application and use Spring Security to tie into Active Directory.

In the end, the decision was made to not use Liferay because we didn't want all of the extra overhead of a portlet container when we didn't need all of the extra stuff, and also wanted to maintain full control / flexibility over exactly how everything was strung together.

Solution 2

Disclaimer: I work for Liferay now; however, I answered this question long before I started to work here. Also, Liferay has pivoted a bit in these years. Nonetheless, I believe the core of the answer still applies.

My companyThe company I worked for is a Liferay Inc. partner, so I have a lot of experience in it. Also, maybe you want to take my opinions with a grain of salt :)

We have used various Java portal tools, and the truth is: as a corporate portal, Liferay is the best one in the market, AFAIK. It is rich in functionality, has few bugs, its code is well written, the community is very helpful, and it is flexible and customizable, useful for a wide range of necessities.

Nonetheless, Liferay is a portal tool, so it excels as a content-centric platform. If you manage a lot of content (such as news, articles, blogs, wikis and forums), then I would happily recommend Liferay as your platform. In other cases, I would suggest a better consideration. You can use something like an ERP, for example.

Anyway, I have seen Liferay used as a general development platform in various places, and the result is reasonable. One gets a significant productivity boost when using Liferay. You do not need to think about users, permissions, content management... Liferay handles even complex, low-level issues such as clustering and sharding. And the Liferay Service Builder is one of the best scaffolding tools for Java I've seen. When I think about it, I feel that Liferay, with its various out-of-the-box applications and its Service Builder, is like a Ruby on Rails/Django for Java.

OTOH, Liferay is enormous, and it can be a problem. You may get a lot of unused stuff cluttering your platform. You will have to study a vast application, and it will demand much time and effort from you. Unfortunately, Liferay's documentation is poor, to make things worse.(I'd say Liferay's documentation improved a lot since I originally posted this answer.) Since Liferay does solve a wide range of problems, its codebase is big. This complexity can be dispensable in many, if not most, applications.

Also, if your application does not use a lot of content, Liferay can provide various helpful tools, but it will not be the natural environment for using Liferay. You will be locked in the Liferay platform, too, which can restrict your choices. You may want to analyze Liferay tools, but I do not know if it would be a good platform.

To summarize, I would say:

• If you want to use a Java-based portal, or to build a broad, complex portal, I recommend Liferay without restrictions;
• If you want to create an application that manages a lot of content, Liferay is an excellent platform to do it, and I think it may be the best choice;
• If your application is big but not content-centric, I would not recommend Liferay, but it can be useful;
• If your application does not manage a lot of content and is potentially small, Liferay probably will add more complexity than it is worth.

Comments

[cdeszaq]

I agree 100% with everything you said. For our app, it is much more action-focused and data oriented, rather than content oriented, and it's also rather small. Platform lock-in was also a concern, but if we had more portal-oriented needs, we would have definitely selected Liferay.

[denu]

I don't understand why It have been chosen as best answer. The question was actually is it worth to use Liferay as a portal or not but you gave negative opinion about it although you didn't need to use its portal functionality.

[cdeszaq]

@denu - Liferay is a portlet container and in our case, since we were not developing portlets, it was just being used for the "add-ons" that other tools did better. The OP asked for testimonials and general info about what it did well and what it did not do well. Since the OP didn't say anything about having a portal at all, I'm not sure where you are getting that from. Though I agree that my answer is probably not the best.

[FeinesFabi]

>...its code is well written... Please take a look at com.liferay.portlet.journal.service.JournalArticleLocalServi‌​ceUtil.addArticle(..‌​.). It takes 38 parameters!!!

[brandizzi]

@FeinesFabi that's a lot of parameter, for sure! But there are reasons for that: this function is also called through SOAP and REST webservices that only receive primitive types. In JavaScript, these parameters are passed through an object, it is way clearer there. More importantly, this method should be transient: it persists many rows and if an object persistence fails, it should rollback everything. Many parameters was the solution found to accommodate these and others requirements. There is debate about how to improve it but it is no light-headed, ad hoc design.

[FeinesFabi]

I see - thanks for the explanation. But I'm way past the questioning of the Liferay way. There are so many times when you need param x for method y in service z and you won't find any documentation on it. Even after hours of hunting through the web. Anyway, my client (rather big automobile manufacturer in Germany) starts to see that the implementation of the requirements is way to expansive in Liferay and is moving towards other systems.

[FeinesFabi]

@threeFourOneSixOneThree I admit I don't know about any other Portals. I've quit the project and am now working in a Grails and AngularJs scenario. It was a good move - things are finally fun again.

[kasakka]

Having worked with LR 6.2 for over 6 months now, I can not recommend it at all. It has extremely lacking documentation and no comments in source code. It is also buggy, stock user interfaces are poorly designed and doing even simple things with the VM/FTL templates seems to often require half a page of code because LR does not provide any reasonable methods to access common things easily. Theme AUI CSS is very intrusive (while unstyled has no styles for admin UI). Deployments with Maven are also quite slow for themes and often fail randomly due to LR bugs.