Deploying A Customized Liferay

As described in the Installation chapter of this book, Liferay allows for complete customization of the portal through the Extension Environment. Deploying the extension environment to a server requires one of two scenarios:

• The Liferay development tools (JDK, Ant, etc.) are installed on the server, the Liferay Portal source code is available on the server, and the extension environment is checked out to a directory on the server.

• On a client machine which contains the Liferay development tools, a drive can be mapped or a folder mounted which points to the installation directory on the server.

Once one of these two requirements have been met, deploying to the server becomes as easy as deploying locally to the developer's machine.

Deploying Directly on the Server

Deploying the extension environment directly on the server is the recommended method. To do this, you will have to create two new configuration files which define the settings for the deployment. In the extension environment, create a file called app.server.<username>properties, where <username> is the user name of the account under which the server executable runs. If, for example, you have a Glassfish server running under the user name of glassfish, your file would be called app.server.glassfish.properties. This file will override the default values which are found in app.server.properties. You will need to configure two properties in this file: the server type and the server path.

The server type should be one of the following:

app.server.type=geronimo-tomcat

app.server.type=glassfish

app.server.type=jboss-tomcat

app.server.type=jetty

app.server.type=jonas-jetty

app.server.type=jonas-tomcat

app.server.type=resin

app.server.type=tomcat

The path property is similar to the server type. It should look like this:

app.server.<server name>.dir

Replace <server name> with the server type above. For example, if you are using Glassfish, your property would be:

app.server.glassfish.dir=/home/glassfish/glassfish-v2

The value of the property should be the fully qualified path to the server directory.

Next, create another file similar to the first one called release.<username>.properties. Again, substitute <username> with the user name the server runs under and under whose credentials you will be doing the deployment. This file will override the default values found in release.properties.

This file requires two properties:

lp.source.dir

lp.ext.dir

Set the value for the lp.source.dir property to be equal to the fully qualified directory name for where you have installed the Liferay Portal source. Set the value for the lp.ext.dir property to be equal to the fully qualified directory name for where you have installed the Extension Environment you have checked out from your source code repository. For example:

lp.source.dir=/home/glassfish/lportal/portal

lp.ext.dir=/home/glassfish/lportal/ext

Once you have set up these two properties files, run the following Ant task:

ant deploy

Your customized Liferay will be automatically compiled and deployed to your application server.

Deploying from a Client Machine

If you will be deploying a customized Liferay from a client machine, you will need to map a drive (on Windows) or a folder on your file system (Mac or Linux) to the server. Once you have done this, follow the same procedure outlined above, with the exception that the <username> should be the user name of the user logged in to the client, not the user name on the server. You will not need to change the release.<username>.properties file; only the app.server.<username>.properties file will need to be modified.

If you are using a developer's machine to do the deployment, these configuration files will already exist. Modify the app.server.<username>.properties file to match the application server type and location of the directory in which it is installed from your mapped drive or folder. Then run the above Ant task to deploy the extension environment.

Note that this second method is not a best practice, as it enables changes to be made locally on a developer's machine which can then be deployed directly to a server without source code management being done first. It is better to have developers check in all their code, version that code, and then pull that version from your source code management software to deploy it to a server.