Ant-based development used in the Liferay SDK fell out of favor with developers a long time ago; modern build tools such as Maven are now all the rage. Although it took Liferay a while to update the tool chain, Maven is now a supported Liferay build tool.
You’ll find that converting from the SDK to Maven is not too difficult once you’ve done it a few times. We’re going to present a few pointers to help convert your plugins from the SDK. This post talks about Migrating Liferay SDK to Maven; specifically, how to migrate your existing projects.
For all of the plugins you’re going to convert, there’s a basic process that you’re going to follow:
- Create a new Liferay Maven plugin project using the appropriate archetype.
- Copy files from the SDK to the appropriate directories in the new Maven project folder.
- Edit the pom.xml file to add necessary dependencies.
Creating the Liferay Maven Plugin Project
The best way to start a new Maven project is to use the “mvn archetype:generate” command and pick the appropriate archetype. This will create a new project with the correct directory structure for the project.
Use the table below to help pick the right archetype for your Liferay plugin:
|Plugin Type||Maven Archetype||Description|
|Layout Template||liferay-layouttpl-archetype||This is the archetype for the layout templates.|
|Theme||liferay-theme-archetype||This is the archetype for theme plugins.|
|Portlet w/ ServiceBuilder||liferay-servicebuilder-archetype||Use this archetype for portlet plugins that have ServiceBuilder service.xml file.|
|Portlet||liferay-portlet-archetype||Normally you’d pick an appropriate portlet archetype based on the framework you’ll be using for implementation; since your portlet is already created you’ll be adding your code in so a specific framework selection is not necessary.|
|EXT||liferay-ext-archetype||This is the archetype for EXT plugins.|
The group id for your project is, well, yours to assign, as is the artifact id and the version number. For the artifact id, it is best practice to add the plugin type as a suffix, for example “customers-portlet” or “poll-customizer-hook” or some such. The exceptions to this rule is the EXT and ServiceBuilder portlet plugins; those do not need a suffix.
Copying Files from SDK to the Maven Project
In the src/main folder in your new Maven project, you’ll typically find a java folder, a resources folder and a webapp folder.
Java sources from your SDK project’s docroot/WEB-INF/src directory should be copied to the java folder. Any non-Java files in that directory should be copied to the resources folder (plus any files that you may have manually dropped in the WEB-INF/classes folder).
All of your other files from the SDK docroot folder (except for anything in the WEB-INF/lib directory) will get copied to the webapps folder, including the various files from WEB-INF such as the web.xml file, other xml files, etc.
There are some exceptions to these general steps:
- For theme projects, Maven doesn’t use the _diffs folder. Your overlay files just go directly in the src/main/webapp directory. At build time Maven will expand the parent theme in the target directory, overlay your changes and then build your theme war artifact.
- ServiceBuilder portlet projects are completely different animals and will be covered in a separate blog post.
- EXT plugins are completely different animals and will be covered in a separate blog post.
When Maven is compiling the Java code, it will use dependencies identified in the pom.xml project file. Any jars that you may have manually dropped in docroot/WEB-INF/lib for your SDK project should be listed as dependencies in the Maven pom.xml file. At build time, Maven will pull the dependencies from the local or remote repositories and include them in the built war file.
Also, any dependencies that you may have listed in the liferay-plugin-package.properties file also need to be added to the pom.xml. As there are a couple of different options here, there’s a separate blog entry that discusses migrating your liferay-plugin-package.properties to Maven dependencies.