Creating Nuxeo Packages

This section gives instructions on how to wrap a plugin and its required dependencies into a Nuxeo Package.

A package contains usually new features or patches along with installation instructions. Packages can be downloaded from a remote repository and then installed on a running Nuxeo and possibly uninstalled later. A Nuxeo Package is the easiest way to distribute a plugin, as it contains in one single zip file all the bundles, libraries and runtime properties that would be required to make your new plugin work. Nuxeo uses the Nuxeo Package format for distributing all its plugins on Nuxeo Marketplace. We also encourage you to use it for delivering your customization. A Nuxeo Package can be set up either in the admin center on the Nuxeo instance, or using nuxeoctl instructions.

Some packages require the server to be restarted after the install (or uninstall). Each package provides a description of the modifications that should be done on the running platform in order to install a package. We will call "command" each atomic instruction of an install or uninstall process. When Commands are revertible - so that for any command execution there must be an inverse command that can be executed to rollback the modification made by the first command. When designing update packages you must ensure the installation is revertible if needed.

The rollback of an installation is done either when the installation fails (in the middle of the install process), either if the user wants to uninstall the package.

In this chapter we will discuss about the package format, package execution and rollback. 

Package Format

A package is assembled as a ZIP file that contains the bundles, configuration files or libraries you want to install, along with some special files that describe the install process.

Here is a list of the special files (you should avoid to use these file names for installable resources)

• package.xml - The package descriptor describing package metadata, dependencies and custom handlers to be used when installing. See Package Manifest for more details on the file format.
• install.xml - A file containing the install instructions. There are two possible formats for this file: either an XML package command file, or an ant script to be used to install the package. Using ant is discouraged, you should envisage to use the package command to describe an installation rather than ant since rollback is ensured to be safe.  See Scripting Commands for more details on the commands file format.
• uninstall.xml - A file containing the uninstall instructions. When using commands to describe the install process this file will be automatically generated (so you don't need to write it). When using Ant for the install you must write the uninstall Ant file too. 
• install.properties - A Java property file containing user preferences (if any was specified during the install wizard). This file is automatically generated by the installer.
• backup - A directory created by the install process (when using commands to describe the install) to backup the existing files that were modified. The content of this directory will be used by the rollback process to revert changes. See Scripting Commands for more details on rollback.
• license.txt - A text file containing the license of the software you want to install. This file is optional.
• content.html - A file containing an HTML description of you package. This file can use references to resources (such as images) located in the package zip - for example you may want to display a set of screenshots for the new feature installed by the package. This file is optional.

• forms - A directory containing custom wizard form definitions. This directory and all the files inside are optional.

  Forms, which are base on the ParametrizedCopy command, are more or less deprecated since they currently work only under the following conditions (NXP-14777):

  • not under Windows,
  • MP is hotreloadable (NXP-8241),
  • DEV mode is activated.

  Instead, you should use a custom configuration template deployed and activated by the MP, then configured by the server administrator from nuxeo.conf.

  There are three type of wizard forms you can contribute:

  • install.xml - Describe install forms (i.e. forms added to the install wizard for packages that needs user parameterization)
  • uninstall.xml - Uninstall forms (i.e. forms added to the uninstall wizard for packages that needs user parameterization)
  • validation.xml - Validation forms (i.e. forms used by the install validator if any is needed)

Apart these special files you can put anything inside a package (web resources, jars, Java or Groovy classes etc.). It is recommended to group your additional resources in sub directories to keep a clean structure for your package.

You can see that most of the files listed above are optional or generated. So for a minimal package you will only need 2 files: the package.xml and the install.xml file.

The Package Manifest

The package metadata is stored in package.xml file.

Here is the list of mandatory and highly recommended properties defining a package:

• name: The package name.
• version: The package version.
• title: The package title to be displayed to the user.
• type: The package type. One of: studio, hotfix, or addon.
• platforms: A list of supported platform versions.
• vendor: The identifier of the package vendor.
• home-page: An URL to the home page of the package (or documentation) if any.
• visibility: The visibility determines the channel where the package will be distributed on (for public, private or registered users).

For more information on the package properties and the XML format see the Package Manifest.

Scripting Commands

XML Commands are the default way to describe the installation instructions. The advantage of using commands is that the rollback and uninstall scripts will be automatically generated.

See Scripting Commands for more details on using commands.

Below is the list of available properties you can use in command files to parameterize your commands.

Using Ant for the Scripting Commands (deprecated)

When using Ant you must write two scripts: the install.xml and uninstall.xml files. Each of these scripts must have at least two targets. The default target of the install.xml script will be used to execute the installation. The other required target of the script is a target named rollback which will be called to do the rollback if anything went wrong during the installation (i.e. during the execution of the default target). The same rule applies for the uninstall.xml script.

See below the list of useful properties that will be injected in the Ant context and thus are available in the scripts.

Context Properties Available in Scripting Commands

Here is the list of properties available to install scripts:

• all the system properties in the running JVM.
• package.id: The Package identifier.
• package.name: The Package name.
• package.version: The Package version.
• package.root: The root folder of the package (the folder containing the exploded zip).
• env.server.home: Since 5.5. The Nuxeo server home. ($NUXEO_HOME).
• env.home: The Nuxeo Runtime Environment home. ($NUXEO_HOME/server/default/data/NXRuntime on JBoss, $NUXEO_HOME/nxserver on Tomcat).
• env.ear: JBoss only. The nuxeo.ear directory ($NUXEO_HOME/server/default/deploy/nuxeo.ear).
• env.lib: The Nuxeo lib directory ( nuxeo.ear/lib on JBoss, $NUXEO_HOME/nxserver/lib on Tomcat).
• env.syslib: The host application lib directory ($NUXEO_HOME/lib).
• env.bundles: The Nuxeo bundles directory ( nuxeo.ear/bundles on JBoss, $NUXEO_HOME/nxserver/bundles on Tomcat).
• env.config: The Nuxeo config  directory ([nuxeo.ear/config](http://nuxeo.ear/config) on JBoss, $NUXEO_HOME/nxserver/config on Tomcat).
• env.templates: The configuration templates directory. ($NUXEO_HOME/templates).
• env.hostapp.name: The host application name (Tomcat or JBoss)
• env.hostapp.version: The host application version (e.g. Tomcat or JBoss version)
• sys.timestamp: The timestamp when the install task was created - a string in the format yyMMddHHmmss.