« Back to Using IntelliJ...

Running Liferay from IntelliJ

Tags: intellij 6.x

There are several ways how we can run Liferay portal from IntelliJ.

Live JSPs Hot deploy Fast development Exploded deployment
Remote no no no no
Local Bundle no / yes yes no no
Local Exploded yes yes yes yes

Note: see also Liferay dev with IntelliJ.

Remote start configuration means that server is started manually by developer and that then IntelliJ connects to it. For each app server there is IntelliJ support for running remotely.

Local Bundle start configuration defines app server that already has the portal deployed within. Deployment is done manually or through ant/batch script, but now IntelliJ is the one that starts the server and the portal.

Local Exploded start configuration does both things: first is to deploy the portal (artifacts) as exploded ee/web application and then to start the app server with it. Here IntelliJ is the one who has to deploy the application. Depending of app server, sometimes this is not always possible to do so.

In practice, author of this article switches between Bundle and Exploded way. If you choose the same or if you run Liferay on many different platforms here is a good tip: set liferay.home property in portal-ext.properties to points to the same location. By sharing this location among start configuration many things will be easier: for example, image uploaded on one app server will be available on other app server, too.

Liferay on Tomcat#

The following is an example of starting Liferay portal on Tomcat.

Remote Tomcat bundle #

There is nothing much to configure here - just use Tomcats plugin for it.

Now you have to start Tomcat manually (out of IntelliJ) and then to connect remotely to it.

Local Tomcat Bundle #

This is a way better way to start Tomcat, directly from IntelliJ. We are still required to invoke Ant tasks for compile/deploy, but we can run and debug Tomcat from IntelliJ.

When Tomcat is started from IntelliJ, hot deployment of changed classes will be available! However, changed JSPs and resource can't be packed (deployed) by IntelliJ, but only from Ant (hopefully, there is a portal-web>deploy-fast target:)

First, we need to define Tomcat server:

Here we define Tomcat from folder where server was already installed and where Liferay was deployed to. Then we can proceed with setup of Run configuration. Choose previously created application server and set the following VM parameters:

 -Xms128m -Xmx1024m -XX:MaxPermSize=128m -Dfile.encoding=UTF8 -Duser.timezone=GMT 

Note that we do not have any artifact to deploy, since we are deploying Liferay manually (using Ant). IntelliJ will show a warning about missing artifact, but we can ignore it.

Although now you can run Tomcat from IntelliJ, there is one more thing to configure. By default, IntelliJ changes CATALINA_BASE location of Tomcat when it starts an application. As a consequence, Liferay bundle would be started differently. To fix this, we have to manually set the CATALINA_BASE to points to Tomcats bundle folder.

Fortunately, there is a trick so we do not need to hardcode the path in the Run and Debug configuration: it is just enough to define an empty CATALINA_BASE environment variable and everything will work as expected:

Now you can start and control Tomcat directly from IntelliJ! Still, deployment is done out of IntelliJ.

Enabling Live JSPs #

The main issue with described Local Tomcat configuration is that live JSP editing is not supported, since deployment is not done by and is not in control by IntelliJ. Hopefully, IntelliJ is smart enough to help us here;) Here is how to enable live JSPs with Local Tomcat configuration.

For this we need a simple artifact:

Artifact should contain just portal-web web facet and the output directory has to point to the Tomcat bundle ROOT application.

Download AutoPackage plugin and enable it for the portal-web module.

That is all!

Local Tomcat Exploded (with Artifacts) #

The third option is to deploy Liferay project as an artifact directly from IntelliJ. For this we need some more tweaking.

With this approach everything is done with IntelliJ: compiling, deploying etc. Therefore, development will be significantly faster! But you must be aware that some things are different: all modules are deployed exploded (this can be configured differently, but then we will loose performances) and some paths will be different. Stay aware of this!

Another nice benefit is so called 'live development'. With help of AutoPackage plugin you can modify JSPs (and resources) and the changes will be visible immediately!

And last, but not least, this approach allows hot redeploy of modified java classes (as much as VM allows: if method signature is not changed etc).

Tomcat #

There is no special requirement for Tomcat in this configuration. Just use one we already have, from the bundle, already defined in previous configuration.

Another option is to use clean Tomcat installation (not from bundle), and then to configure it manually for Liferay portal. Such Tomcat we can call as 'external'.

Javac resource patterns #

In File>Settings>Compiler option set for all resources to be included and copied during compilation.

Module: definitions #

We need a new module: definitions. It has no dependencies.

One important note: up to now, IntelliJ module files for each module were placed in module root (as IntelliJ suggested by default). This time, however, we will make an exception, since definitions should be clean of other non-project files. For that reason, we will put IntelliJ module file in the projects root instead of module root. It will be also automatically ignored on svn.

Module: dependencies #

The module dependencies has to be a mirror of a portal-impl/classes/com/liferay/portal/deploy/dependencies. The best way to achieve this is to make symbolic folder link to it (since we can't create a IntelliJ module which source is inside of other module source path). Alternatively, you can simply copy this folder to projects root (without linking), but then you have to maintain changes manually.

Folder dependencies contains bunch of .xml and .tld files and some .jar files as well. Here is a partial file list so you can easily find this folder:


One important note: up to now, IntelliJ module files for each module were placed in module root (as IntelliJ suggested by default). This time, however, we need to make an exception: folder dependencies might be recreated when invoking some Ant tasks (such: ant all). Therefore, module file might get deleted. For that reason, we will put IntelliJ module file in the projects root instead of module root. It will be also automatically ignored on svn.

Now, we can create a module:

However, up to now, folder dependencies is not ignored on SVN, and IntelliJ will add folder and its files to 'Unversioned files'. To prevent this we can use a simple trick. Since all .iml files are ignored, we can rename the folder as e.g. dependencies-link.iml. Now subversion will ignore it and everything else will be the same.

Module: sql #

Folder sql is another folder that has to be deployed together with the application. We need just the root and can ignore all subfolders.

Artifact: portal-service #

First artifact is portal-service.jar. Since this jar is not located under web application (in WEB-INF/lib folder), artifact is server-depended: the output path has to be set to it's real location.

Artifact: exploded #

Next artifact is a web exploded artifact liferay exploded. Configure it as it is shown here:

Run Configuration #

Select Tomcat application server (one from bundle), add VM parameters and this time add artifacts which gonna be deployed. That’s all!

Warning: when running Tomcat this way you might become unaware of possible structure changes of Liferay projects (that might happen in future). It is strongly recommended to perform regular deployment using Ant from time to time!


Build two artifacts:

Deploy the artifact:

Done! Now you can both deploy and run Tomcat from IntelliJ.

More #

This is not all. There are many ways and variations how you can configure IntelliJ and artifacts to run an app server. Here are some ideas:

  • build an exploded WAR artifact (similar as above), but with portal-.jars. The results will be very similar to what ant deploys.
  • build just jars directly in place, and deploy the rest of the content manually (using Ant)
  • Use clean installation of Tomcat (external), instead of bundled one. Here you can set ROOT.xml to points to the IntelliJ artifact exploded folder.
14 Attachments
Average (0 Votes)
The average rating is 0.0 stars out of 5.