Liferay Portal Systems Development: Build dynamic, content-rich, and social systems on top of Liferay with this book and ebook

Plugins SDK is a simple environment for plugins development such as Ext (Ext stands for extension) plugins, themes, layout templates, portlets, hooks, and webs (web applications). It is completely different from the Liferay portal core services as it uses external services portal-service only if required.

In order to set up the development environment, Plugins SDK for development, customization, deployment, and debugging, we need to consider the following aspects: required tools, databases, application servers, IDE (Integrated Development Environment), portal runtime bundle, and portal source code. We will have a deeper look at these aspects.

Of course, you can use Liferay Developer Studio, where all aspects are packaged as one simple bundle or Liferay IDE. Liferay IDE is an extension of the Eclipse platform that supports development of plugins projects such as portlets, hooks, layout templates, themes, and Ext plugins—as you can see, webs...

Before navigating to the portal runtime structure, portal source code structure, plugins runtime structure, and plugins SDK source code structure, let's first build a portal source code Java project named portal-trunk (represented as a variable $PORTAL_SRC_HOME) and a plugins SDK source code Java project named plugins-trunk (represented as a variable $PLUGINS_SDK_HOME).

Using the IDE, you will see the portal source code Java project portal-trunk and the plugins source code Java project plugins-trunk.

In addition, you may be interested in Alloy UI source code. Therefore...

Liferay portal provides a tool named Service-Builder, which could automate the creation of interfaces and classes for database persistence, local and remote services. In brief, Service-Builder will generate most of the common code needed to implement, find, create, update, and delete operations on the database, allowing developers to focus on the higher-level aspects of the service design directly.

The term service is a class or set of classes designed to handle retrieving and storing data classes. A service could be local or remote. A local service is used in the local Liferay instance, while a remote service is accessible from anywhere. By default, remote services support SOAP, JSON, and Java RMI. This section is going to discuss Service-Builder in the portal core, and the next chapter is going to focus on Service-Builder in plugins.

Now you can start the portal. As you have noticed, the default database, Hypersonic, and the default data are in use. As shown in the following settings, Liferay is configured to use Hypersonic as its database. Do not use Hypersonic in production. Hypersonic is an embedded database useful only for development and demo purposes. The default database settings are defined in portal.properties, which can be overridden by creating portal-ext.properties.

# Hypersonic
jdbc.default.driverClassName=org.hsqldb.jdbcDriver
jdbc.default.url=jdbc:hsqldb:${liferay.home}/data/hsql/lportal
jdbc.default.username=sa
jdbc.default.password=password

As shown in the preceding code, the default data is stored at $LIFERAY_PORTAL/data/hsql/lportal.script. Moreover, the portal provides a dialect detector in com.liferay.portal.spring.hibernate.DialectDetector. This dialect detector will check dialects such as HSQL (Hypersonic), ASE (SybaseASE15Dialect), DB2 (DB2Dialect), Microsoft (SQLServer2008Dialect...

Plugins SDK provides default plugins project creation and templates, which are used in Liferay IDE. This section is going to show you the default creation scripts and default templates.

create.sh: ant -Dext.name=$1 -Dext.display.name=\"$2\" create
create.bat: call ant -Dext.name=%1 -Dext.display.name=%2 create

create.sh: ant -Dhook.name=$1 -Dhook.display.name=\"$2\" create
create.bat: call ant -Dhook.name=%1 -Dhook.display...

What is fast development of plugins? Fast development allows developers to work with exploded plugin WARs instead of having to package them for deployment. For example, if you change JSP files in a plugin, these JSP files will be modified when you refresh the page in your browser. Furthermore, if you update other files (for example, JSF pages, Java beans, servlets, and so on) besides JSP files, these files will automatically be reloaded by the class loader of Tomcat. Obviously, this will save a lot of development time.

How do we make it happen? Firstly, you need to add a new Ant target deploy-exploded inside the file $PLUGINS_SDK_HOME/build-common-plugin.xml as follows:

// after <target name="deploy" depends="war">
// <copy file="${plugin.file}" todir="${auto.deploy.dir}" />
// </target>, add following lines:
<antelope:stringutil string="${basedir}/${plugin.name}.xml"
property="plugin.context.file">
<antelope:replace regex="\\" replacement="/" ...

This chapter discussed how to set up, build, and deploy the portal core and plugins in the Eclipse IDE. Then it discussed how to use Service-Builder to generate services and models, and how to add new features to the Service-Builder. It also addressed how to populate the default data, how to use the default project creation and templates, and how to set up fast development of plugins with Tomcat.

In the next chapter, we are going to use Plugins SDK for building generic MVC portlets.