As a Liferay developer, you’re undoubtedly already familiar with the concept of plugins (portlets, themes, etc). If you’re not familiar with Liferay plugins, see the introductory section of Liferay developer tutorials. A Liferay App (sometimes just called an app) is a collection of one or more of these plugins, packaged together to represent the full functionality of an application on the Liferay platform. In addition to the plugins contained within an app, apps have metadata such as names, descriptions, versions, and other information used to describe and track the app throughout its life cycle.
Much like standard Liferay plugins, Liferay apps are also hot-deployable. Liferay Marketplace apps are distributed via a special file type with a
.lpkg extension. To deploy these files, drop them into a running Liferay instance’s hot-deploy folder (
[Liferay_Home]/deploy), like any other plugin.
As an app developer, you’re not required to create the
.lpkg files. Instead, your app’s individual plugins (WAR files for traditional plugins or JAR files for OSGi modules) are uploaded as part of the publication process, along with information (name, description, version, icon, etc.) that identifies the app. The publication process is described in detail later.
At this point in preparing to publish your app, you’ve developed your app. And if you’re preparing a paid app, you’ve specified a permission descriptor (a portal access control list (PACL) for traditional plugins or a
OSGI-INF/permissions.perm file for OSGi modules), so that your app can be deployed on Liferay instances that have their Plugin Security Manager running. But before you start the formal publishing process, you must prepare your app’s files and app metadata.
Marketplace App Metadata Guidelines
The following app metadata guidelines are intended to ensure that apps are submitted with important and necessary supporting information. The metadata that you submit with your app will serve both as necessary information for your app’s buyers (e.g., your contact info) and as promotional assets (e.g., description, screenshots, etc.) that can help drive traffic to and downloads of your app!
You’ll want to think of a good name and description of your app. If you haven’t already done so, take some screenshots, design an icon, and create a website for your app. The table below can help guide you address the Marketplace app metadata requirements and produce an appealing advertisement for your app.
Marketplace App Metadata Guidelines:
Make sure your icons, images, descriptions, and tags are free of profanity or other offensive material.
During the publication process, you upload your app’s individual plugin WAR files and module JAR files along with the app’s metadata (name, description, version, icon, etc.).
Additional Requirements for Themes/Site Templates
A theme without content is like an empty house. If you’re trying to sell an empty house, it may be difficult for prospective buyers to see its full beauty. However, staging the house with some furniture and decorations helps prospective buyers imagine what the house might look like with their belongings. Liferay’s resources importer application is a tool that allows a theme developer to have files and web content automatically imported into the portal when a theme is deployed.
All standalone themes that are uploaded to Liferay Marketplace must use the resources importer to include files/web content to provide a sample context for their theme. This ensures a uniform experience for Marketplace users: a user can download a theme from Marketplace, install it on their portal, go to Sites or Site Templates in the Control Panel and immediately see their new theme in action. You can read more about themes in the Themes and Layout Templates tutorials.
Liferay apps are “normal” Liferay plugins with additional information about them. Therefore, most of the requirements are the same as those that exist for other Liferay plugins, as explained in the tutorials on creating MVC Portlets and JSF Portlets.
In addition to those requirements, there are some Marketplace-specific ones to keep in mind:
Target the Appropriate Java JRE: Regardless of the tools you use to develop your app, your app’s bytecode must be compatible with the target Java JRE for your version of Liferay. Your app will be rejected if its bytecode is not compatible with the Java JRE for the intended version of Liferay. Liferay 6.2 targets Java 1.7, and Liferay 7.0 targets Java 1.8. If you use the Liferay Plugins SDK to develop your app, you can set the Java version by overriding the
ant.build.javac.targetproperty in the Plugins SDK’s
- WAR files must contain a
- WAR files must not contain any
- WAR file names must not contain any commas.
- WAR file names must conform to the following naming convention:
- context_name: Alpha-numeric (including
_) short name of your app. This name is used as the deployment context, and must not duplicate any other app’s context (you’ll be warned if you use a context name of any other app on the Marketplace).
- plugin_type: one of the following:
A.B.C.D: The 4 digit version of your WAR file. 4 digits must be used.
- WAR files must contain a
recommended.deployment.contextmust not be set.
- Setting property
trueis mandatory for all paid apps on 6.1 CE GA3, 6.1 EE GA3, and later; the setting is optional for free apps. Setting this property to
trueenables Liferay’s Plugin Security Manager. If you’re enabling the security manager, you’ll also need to define your Portal Access Control List (PACL) in this file. Read Plugins Security and PACL for information on developing secure apps.
- Deployment contexts:
- Liferay reserves the right to deny an application if any of its plugin deployment contexts is the same as a context of another plugin in the Marketplace.
- Liferay reserves the right to replace app plugin WAR files that have the same deployment context as plugins built by Liferay.
There are some additional requirements for uploading Liferay 7.0 apps:
OSGi modules in JAR (
- For more information, see OSGI and Modularity - Modules.
- The manifest file must at minimum contain the following manifest headers:
Bundle-SymbolicName: a unique name for the module
Bundle-Version: the module’s version
Web-ContextPath: the servlet context path
- WAR-based plugins must be adapted to run on Liferay 7.0. See this tutorial for information on adapting WAR plugins that run on Liferay 6.2 and earlier to run on Liferay 7.0.
Apps containing multiple file types:
- Liferay 7.0 apps can contain a mix of WAR-based plugins and OSGi JAR-based plugins. Regardless of file type, each plugin must be able to run on Liferay 7.0.
Apps usually consist of multiple plugins (e.g., multiple WAR or JAR files) and plugin types. In addition, you may want to consider how to package your app for running on different Liferay versions.
Considering Package Variations to Target Different Versions of Liferay
Apps can be written to work across many different versions of Liferay. For example, suppose you want to publish version 1.0 of your app, which you’re supporting on Liferay 6.1 and 6.2. Due to incompatibilities between these Liferay versions, it may be impossible to create a single binary WAR or JAR file that works across both Liferay versions. In this case, you must compile your app twice: once against Liferay 6.1 and once against 6.2, producing 2 different packages (also called variations) of your version 1.0 app. Each package has the same functionality, but they’re different files. You can upload such packages to support your app on different Liferay versions. With regards to Liferay apps, packages are sometimes referred to as files that make up your app.
Now that you’ve prepared your app’s files and specified its metadata, it’s time to get it to submit it to Liferay for publishing on the Marketplace!