Liferay Maven SDK

Starting to recover from jetlag after a two week trip Los Angeles and Liferay retreat. One of the things we finally made some progress during the developer retreat  is providing official maven artifacts for Liferay as well as porting our plugins sdk to Maven. Things are not quite completed but I will provide some instructions here for all early adopters.

So our goal is to provide our CE releases through our own public repository as well as provide means for our EE customers to install the EE versions artifacts to their local maven repository.

If you have ever worked with enterprise projects using maven you already know how important a local maven repository and proxy is. For those not so familiar with Maven a proxy is a server that proxies your requests to public Maven repositories and caches the artifacts locally for faster and more reliable access. Most maven proxies can also host private repositories used for hosting your company's private artifacts. Having a local proxy / repository makes your maven builds much faster and more reliable than accessing remote repositories that might even sometimes be unavailable.

1. Installing a maven proxy / repository

First step is to install and setup Nexus. Nexus is a open source maven repository manager that can proxy to other repositories as well as host repositories. If you just want to try things locally you can skip this step.

  1. Download latest Nexus such as
  2. Follow the installation directions of the Nexus book
  3. Startup nexus
  4. Open your browser to your newly created nexus (if you installed it locally it could be accessed by opening http://localhost:8080/nexus)
  5. Login as administrator (default login is admin / admin123)
  6. Go to Repositories and click Add -> Hosted Repository
  7. Give the repository following information and click save
    • Repository ID: liferay-ce-releases
    • Repostory Name: Liferay CE Release Repository
    • Provider: Maven2 Repository
    • Repository Policy: Release
  8. Create another hosted repository with following information
    • Repository ID: liferay-ce-snapshots
    • Repository Name: Liferay CE Snapshot Repository
    • Provider: Maven2 Repository
    • Repository Policy: Snapshot

Now you have a repository ready for Liferay's Maven artifacts. Next step is to configure your maven to be able to upload artifacts to that repository.

 2. Configuring Maven Settings

Open your $HOME/.m2/settings.xml (if the file does not exist create it). Add the servers segment to your settings.xml

<?xml version="1.0" encoding="UTF-8"?>

You might also want to make your Nexus as your maven proxy. To do that just add following xml segment to your settings.xml right before servers element.

          <name>Local mirror repository</name>

3. Installing Liferay Artifacts to Repository

Next we will install the Liferay Maven artifacts to your repository. First you need to checkout Liferay code from the SVN. 

svn --username guest co svn:// portal-trunk

Guest user does not require password.

Then create a release.${username}.properties file and add


Build Liferay artifacts by running

ant clean start jar

Now you can deploy the Liferay artifacts to your maven repository by running

ant -f build-maven.xml deploy-artifacts

If you only want to have them locally without a maven repository you can run the install task instead of deploy

ant -f build-maven.xml install-artifacts

Now you can add Liferay dependencies to your maven project. Following artifacts are available:

NOTE portal-impl and portal-web are provided for maven plugins and should never be added as dependency to your Liferay plugins.

 4. Installing the Liferay Maven SDK

To take full advantage of Maven we are porting the functionality of out ant based Plugins SDK to Maven. To use it you need to install it locally. To install the Liferay maven plugins and archetypes go into support-maven folder and run

mvn install

Now the Liferay Maven SDK is installed and ready to use. We've implemented a portlet archetype and deployer plugin.

5. Creating a Portlet Plugin

Move to the folder where you want to create your portlet and run

mvn archetype:generate

From the list select liferay-portlet-archetype and provide your project groupId, artifactId and version for the portlet project.

You're portlet project's pom.xml has two properties and liferay.version. These properties are usually moved to your parent pom.xml or settings.xml so that you don't have to adjust them for every single plugin you create. Set the to point to the Liferay autodeploy directory of your Liferay bundle. This is where the deploy plugin will copy your portlet. Now you are ready deploy your newly created portlet. You can deploy it by running

mvn liferay:deploy

6. Future Plans

We are also in the process of adding archetypes for themes, hooks and layouts as well as providing portlet archetypes for different types of portlets like JSP, Spring MVC, JSF etc. I will blog about it once they are done.

A special thanks goes to Thiago Moreira and Brian Chan for making this possible. Also for the community and customers for putting pressure to have this done.

If you are using 5.2.3 CE and want to take advantage of Maven for building Liferay portlets Milen Dyankov a Liferay community member has done also great work on a Maven SDK for 5.2.3 CE. You can find more about it from GitHub

Thank you Mika,

yes, yes, yes!!! emoticon

I was waiting for news at, but this information is perfect!

Dreams finally come true! emoticon
Great work! thanks, we can finally mavenize all our Liferay stuffemoticon
Kiitos Mika, this is what the community has been waiting for.

I did modify plugin to work with EE.

Future support for new Extlet would be good also emoticon .. then Liferay customization will be totally mavenized.
The public SVN repo seems to be down. It cannot be access it via
It is up now. Was down for maintenance work.
Hi Mika,
In step 4, I need to install the Liferay maven plugins and archetypes go into support-maven folder and run "mvn install".

But where is the folder? Is it created by one of those 3 ant command before step 4? Thank you.

There's no doubt this certainly is going in the right directio, but suppose you create any type of plugin and you check your code into SVN which will trigger a CI build on your build servers. These build servers will not have any knowledge of Liferay dependencies nor will they allow us to install Liferay on the servers to satisfy those dependencies (if you were to use ANT). This is where Maven comes into the picture nicely. The idea would be that I could create a POM file for my plugin and define a set of dependencies that Liferay maintains in their Maven repository. Some attention would be needed to define which dependencies would be for EE customers too. From there, our build server would build based on the POM and pull down the Maven dependencies to satisfy the requirements for a successful build. Finally, we could then deploy the resulting build artifact (Liferay plugin WAR) to our internal Maven repository for our INFRA team to deploy to the various environments we have. As per Maven’s design we could deploy as a SNAPSHOT build for our DEV/TEST environment and then a Release build with a release number for PROD deployments.

As an example, a POM may define a Liferay dependency as follows like you show above:


We would then define a repository for the Liferay dependencies where we could retrieve this dependency:

<name>Liferay Repsitory</name>

Finally, in your repository, you could establish the transitive dependencies you require (i.e., the ones needed to compile your jar) in your .pom file that will be hosted in the repository so that when someone pulls the Liferay jar it will also pull those dependencies as well. As an example, see the Spring pom from Maven repo that illustrates how they require commons-logging, commons-collections and others. This way you will always have full control of which dependencies you want the customer to use with your JAR so they don’t go and muck things up by using an obsolete version.

I really look forward to seeing Liferay provide Maven dependencies for EE customers as well in a future release.
Is there a wiki page on this that we can edit now. I've been working through the blog but had a number of issues come up. got down to step #5 but have not been able to successfully deploy yet with maven. I got errors in the mvn archetype:generate that are hanging me up.
Thanks for the work, this is a first step for proper Maven support. I just checked the daily build, and the generated Liferay POMs are incomplete - internal portal dependencies are included, but all non-Liferay dependencies are missing. Will this be fixed before 6.0 GA?
Liferay artifacts are provided so that you can develop agains Liferay APIs and this should not require any non-Liferay libraries. If you are referring to portal-impl that is ONLY meant for maven plugins like ServiceBuilder plugin and that plugin will declare itself what it needs. Since we are not building Liferay with maven we won't do double maintenance on the dependencies as those are already mentioned in versions.xml and no one really should use portal-impl in their application anyway. If there is anything else that is actually needed and is missing let me know and I'll fix it.
Mika, thanks for the clarification. I can see why you don't want to do double dependency maintenance. However, what would indeed help developers if you could extend the build-maven.xml to build both the code jars and the java-source jars. The steps to create a source-jar are quite easy. First, create a jar with the plain source, then do something like this:
mvn deploy:deploy-file -DgroupId=$GROUP_ID -DartifactId=$dir -Dversion=$VERSION -Dpackaging=java-source -Dfile=$dir/$dir-sources.jar -DrepositoryId=$REPOSITORY_ID -Durl=$URL

I downloaded the sources from
(By the way, it is very useful to be able to download the source tarbal from a web site !)
The compilation went fine, but there are error due to the changing version number maven expect 6.0.0, but the repository contains version 6.0.1.
I have no SVN access from work.

Will the next version be 6.0.2 ? The hasn't been updated since the 19/04/2010. Also it would be very nice to have the source tarbal in the "nightly" too and not just the war.
I changed 6.0.0 to 6.0.1 in all pom.xml in maven-support and it worked.
I created a portlet with the archetype, configured the deploy property in the pom.
It works great !
Nice, Mika. I took a look at the archetypes and there doesn't seem to be any maven support yet for the ext environment. Is that underway too?
Hi Ken: as the extension environment is moving to "extlets" (that are plugins in the end), that would be possible in a not-that-far future
Added a wiki page with this info
Thank you for this blog and it is a relief to learn that the community is working on getting an integrated solution working with Maven. I went through the steps and there are a few things that I ran into:

1.) I had to set the JAVA_HOME environment variable in order to get the following command to work “ant clean start jar”
2.) I am currently fighting an issue where the liferay artifacts when deployed contain “${maven.version}”. For example: com/liferay/portal/portal-client/${maven.version}/portal-client-${maven.version}.jar. I am not sure how the maven.version variable gets set.

In any event thank you for the maven integration.
The same issue here. When I setup manually the variable "maven.version" in my release.{$username}.properties its ok but then all artfacts get uploaded containing maven version ??? This should be the artifacts' version instead of maven's version, right?
I was able to handle the ${maven.version} problem and some more problems, but I was stuck later... You can find the details (and a solution for the ${maven.version} problem in the following thread:

Any update on #6?

Looking forward to have a painless way to create spring & jsf portlets:-)

Thanks for great explanation.