Table of Contents [-]
- What is Liferay Portal?
- What is the Liferay bundle?
- Liferay Portal Source Code
- Liferay EXT Environment / Liferay EXT SDK
- Liferay Plugins SDK
- Liferay Development Environment
- Source Control
- Where Do I Go From Here?
This page is an introduction to the basic concepts of Liferay and its development.
What is Liferay Portal?#
Liferay Portal is a JSR-168/JSR-286 compliant portal. It is a web application. In a nutshell, you can think of as the portal as one big servlet. It is a servlet that happens to be a portlet container. The portal source builds this portlet container using the Ant build tool and the JDK.
What is the Liferay bundle?#
The Liferay Bundle is Liferay Portal pre-deployed and pre-configured on an application server. You simply download, unpack, and run. No configuration necessary, other than having Java runtime installed on your machine. It comes in many different varieties. The most common is the Tomcat bundle. As of Liferay 5.1.1, these are the bundles available:
- Glassfish 3
- Glassfish 2 for AIX
- Glassfish 2 for Linux
- Glassfish 2 for OSX
- Glassfish 2 for Solaris
- Glassfish 2 for Solaris (x86)
- Glassfish 2 for Windows
- JBoss+Jetty 4.0
- JBoss+Tomcat 4.0
- JBoss+Tomcat 4.2
- Tomcat 5.5
- Tomcat 6.0
The intent of these bundles is to quickly install and experience Liferay Portal without having to do any development builds. You don't even need to configure a database as it uses HSQL embedded database right out of the box.
Note: do not use HSQL in production. It is for demo purposes only!
Do I have to use the bundle?#
You can use the bundle as a starting point, and can deploy onto the bundle with code that you have. You can also use fresh copies of app servers or servlet containers and install Liferay onto it, but you need to do some extra steps before doing a deploy. You must install the Liferay Dependencies first. You can get those here:
For Liferay 5.1.1, it is listed as "Liferay Portal 5.1.1 Dependencies"
So for example, if you do not want to use the Liferay-Tomcat bundle and would rather go straight to Apache's site and download a vanilla Tomcat, you can do so, but you cannot do a deployment of your source code right away. You must install the Liferay Dependencies first, whereas with the bundle, this has been done for you.
Download Liferay Bundle#
Liferay Portal Source Code#
The Liferay Portal source is available under "Files for Developers" at: http://www.liferay.com/web/guest/downloads/additional
For example, the source code for Liferay 5.1.1 is there listed as "Liferay Portal 5.1.1 Source."
Alternatively, you can obtain the source code from SourceForge.net. The project is called "Liferay Portal" and the packages are here: http://sourceforge.net/project/showfiles.php?group_id=49260&package_id=42607. The screenshot below shows the tree for version 5.1.1 and all packages. Fourth from the bottom, you can see "liferay-portal-src-5.1.1.zip"
You can also look for previous Liferay version packages in the tree nodes underneath.
What is the source code?#
Simply put this package is the source code for Liferay portal. You can use Ant to deploy this code onto any number of application servers and/or servlet containers. However, it is not recommended to deploy directly from the source code. What is recommended is that you create or download the "Ext Environment." For an explanation of the EXT Environment, please see below.
Liferay EXT Environment / Liferay EXT SDK#
What is the EXT Environment?#
The Liferay EXT Environment is where you would ideally make changes to the portal itself. In other words, this is where you customize or "extend" the portal. You may ask, "Why can't we just make the changes to the portal source directly?" The answer is that you technically CAN, but if and when you have to upgrade, you will have a tough time sorting out what is out-of-the-box and what is customized. EXT Environment keeps things separate.
The EXT Environment has the portal source packed up within it, and gives you space for your custom code. When you deploy, everything gets packed up into one.
You can either build the EXT environment manually, or download the EXT SDK pre-built for you.
Build EXT Environment#
Download EXT SDK#
If you do not wish to build this yourself, you can simply download it. Liferay has prepackaged it for your convenience.
Find it under "Files for Developers." For example, for 5.1.1, it is called "Liferay EXT SDK 5.1.1"
If I use EXT, why do I need the Liferay source code?#
You need it as reference. For example, if you wanted to change the behavior of the LoginPostAction class. You would do this in EXT. But you need to the original so that you can copy it over to EXT and modify it.
Liferay Plugins SDK#
What is the Plugins SDK?#
The Plugins SDK is an environment where you can develop and build layout templates, themes, and portlets so that they can be packaged into a separate WAR file. In earlier versions of Liferay, the Plugins SDK did not exist and much of the portlet development was done in the EXT Environment. Creating separate WARS for portlets was indeed possible, but the Plugins SDK made this process easier.
Download Plugins SDK#
Find it under "Files for Developers." For example, for 5.1.1, it is called "Liferay Plugins SDK 5.1.1"
Plugins SDK Development#
Portlets in EXT vs. Plugins SDK#
Portlets developed in EXT will be a part of the Liferay web app, while portlets developed in the Plugins SDK will be in their own WAR files. These are deployed as separate web apps, and more modular. Keep in mind you still need Liferay installed to have the plugins work. You can also hot deploy the plugins, so that you do not have to restart Liferay.
Liferay Development Environment#
It is possible to set up a develop EXT SDK and Plugins SDK development environments in different IDE's, including Eclipse, Netbeans, and IntelliJ. There are other wiki articles on how to set these up.
What exactly should you keep under source control?
1) EXT Environment
You can build your whole portal from EXT. Make sure and do an "ant clean" before checking your code in, otherwise you will include many generated files that change every time you do a build.
2) Plugins SDK
You may check in the entire directory, but some choose to only check in the directories that contain the source code for each individual portlet.