Top ten things I learned at Liferay West Coast Symposium 2011

I spent the last couple of days in mostly sunny Anaheim attending the Liferay West Coast Symposium 2011. I also attended last year and found it so useful that I went again this year.

Unlike last year, this year I am going to write a list of the highlights and lowlights of the conference. Without further ado, the list of thing I learned at the symposium

1. Liferay has some good press

As is customary in those sorts of things, the conference started off with a "rah-rah" keynote about how wonderful Liferay is, what a good company they are and other PR related stuff. Normally, I would even comment on this as it happens at every conference everywhere. The details are somewhat different but the message is the same: "Feel good about being associated with us".

However, I had thought during this PR blitz about Liferay as a open-source product and a company that makes money by giving away its primary product. Keep in mind, they do make money as a self-funded and profitable company. The message is that this company and product is competing quite well with all the big players and is gaining market share (according to Gartner) where others are falling out of the picture.

With all this, there is the real stigma of open-source associated with Liferay, evidenced by our on-going negotiations with them to license the product. The proprietary companies have done a great job of down-playing the value of open-source while pushing technologies that lock a customer to a their vendor. Liferay's success in following business model of building a product that is non-proprietary is unique in a world of Oracle, IBM and other companies that see a portal as a way to lock a customer into a vertical and expensive stack.

Lessons learned:

• Liferay is a profitable company
• Using Liferay allows the customer to choose the underlying stack
• We need to do a better job of getting the word out that Liferay is an enterprise level ecosystem and not just an open-source product

Speaking of doing a better job of getting the word out ...

2: Documentation (or the lack thereof)

If there is one failing of Liferay it is in the documentation department. Of course this is a common problem with open-source projects but Liferay is positioning itself to be an enterprise player. One things enterprise customers expect is documentation and support. Liferay's support has been as good if not singularly better that other companies support and we haven't paid them a dime yet.

Their documentation has been really lacking and it showed at the conference. I attended several sessions where the question of documentation was raised. Sometimes people wanted to follow-up on the current topic or some other topic was raised in passing that people were not familiar with. The answer was never "read the fine manual" but was some variation of "check out the source" or "we are working on that". The problem with the lack of documentation is there are a lot features available that customers do not know about. This is one of my main reasons for returning to the symposium this year was to learn what I didn't even know about.

Consider to getting into Disneyland for free and spending your whole day on "Its a Small World". Liferay is a such and extensive product with so many things available for developers, UI people, and content contributors but we don't even know we what are not using.

There are some good things happening with documentation. First, the whole documentation site has been revamped. In the past, the documentation has been hard to access and to find what you were looking for. The new site is better organized but still lacking in actual content (see my service builder section below). There more in-depth articles are needed as well as clearer examples.

Second, there is a new book out Liferay in Action: The Official Guide to Liferay Portal Development and from what I saw, it looks like a must have for Liferay developers.

The chapters include:

• Chapter 3, "A data-driven portlet made easy"
• Chapter 4, "MVC the Liferay way"
• Chapter 5, "Providing your own site design with themes and layout templates"
• Chapter 9, "Liferay architecture and extension points"
• Chapter 10, "A tour of Liferay APIs"

It looks like this book will go a long way to correct the documentation problems with Liferay. Lessons learned:

• Documentation continues to be a challenge, but is being addressed both online and in print
• Much of the current documentation consists of both source code and samples

Speaking of source code ...

3: Liferay is on github

Git is a newer source control system as are subversion and cvs. The github site provides a certal place to host software projects in much the same way source forge does. Liferay has put the source code in github in the liferay project. The advantage is that it is easier to find the source code, especially the sample code, as well as providing a simpler mechanism for submitting patches back to Liferay.

There are also lots of sample portlets in the repository which provide a good starting point for a new project. Lessons learned:

• Liferay source is now more accessible on github
• The sample code can now be easily found

4: Staging

Liferay 6 introduced the concept of staging. This allows the web-site designer to work on updates to the website without affecting what the users sees and then publishing the changes once they are completed. This is a great feature that we will be able to take advantage of with out deployments. It will allow us to make the changes we need to make and get them verified before the night of the production deployment. During deployment we can just publish the changes that have already been verified which will save us all a great deal of time.

Liferay 6.1 takes this idea a step further by allowing multiple staging versions at the same time. The example given was to be working on the Christmas design and the Valentines design at the same time, all while the users are still seeing the current design. This will allow the designers greater flexibility to work in the site without having to worry how the incremental changes appear to the users. Once the work is done, the site can be published.

What was not brought up was how staging works with different version of plugins. It seems like different version of the same war file would need to exist on the server if the new designs require new portlets, themes etc. This should not be a big deal, but will need to be taken into consideration. This that need to be considered is the name of the portlets and the categories so it is clear in the Add Application which portlet is being added.

Lessons learned:

• Staging can be used to safely make incremental changed to a site without impacting users
• Staging may require multiple version of plugins

Speaking of plugins ...

5: Liferay Developer Studio and Liferay IDE

The Liferay Developer Studio and IDE provide some tools to create plugins in a simple wizard way. There are wizards for creating portlets and for creating hooks. The IDE runs in Eclipse and the Studio is built on Eclipse giving them some good tools to work with.

The projects produced are ant based. This is not too problematic in itself, but it is inconvient. A lot of projects, and all of our projects, run under maven. Converting from ant to maven is normally not a huge effort, not of an inconvience. The problem with the projects generated is that the ant build files depend on files outside the projects. This makes it difficult to convert to maven. It also hinders allowing other people to work on the projects without a full liferay EXT environment.

I started paying attention during the sessions and the only time I saw either is when they were being demonstrated. In almost every session, the presenter was using straight Eclipse on a Mac. A few were using Textmate but no one was using the Liferay tools. For what its worth, I didn't see any Netbeans nor EMACS.

Lesson learned:

• The Liferay IDE and Developer Studio have some good tools
• Mostly they are used for getting started on a project and then back to your regular IDE.
• Put all JSPs in a single hook by themselves. Service hooks go in their own war file.

6: Mobile

Liferay 6.0 has detection for mobile devices. Liferay 6.1 improves upon it.

Lessons learned:

• Liferay is actively trying to make mobile work well on the platform.

7: OpenSocial

There was a demonstration of OpenSocial gadgets. They work well and interact with portlets but seem to be simplier to produce.

Lessons learned:

• Not really a lesson but a question: Can OpenSocial gadgets replace some out our portlets?

8: Alloy UI

Alloy UI is Liferay's answer to JQuery. It provides the unified look and feel for the console and can be used in custom plugins. While nice, the lack of documentation and the tighter binding to Liferay make me want to stick with JQuery.

Lessons Learned:

• Ties us to the Liferay Portal
• Documentation is lacking

9: Lifeay Sync

Similar to Dropbox, it allows for sharing of files across devices and the Liferay Document Library. The real strength is to allow content contributors to automatically have their files updated to the server so there is no upload step needed. This can be of great benefit when there are lots of documents being needing to be added to the server.

10: Liferay Marketplace

Liferay is creating a new server called Marketplace. This is the give the same sort of functionality that the App Store gives to iPhones. It allows developers to upload plugins and people can easily find and download them. It looks like it could be a good idea.