Application Manifest

Application Manifest

An application manifest is a JSON-based JPS file that describes the information and configuration required to install an application successfully. It can define application metadata, environment topology, file uploads, deployments and post-deployment configuration.

Manifest Overview

Before packaging an application, deploy it manually first and verify all required settings. This helps identify every configuration value that should later be included in the package manifest.

The JPS manifest is a .json file containing the package definition in JSON format. It may also reference web-based dependencies needed during installation, and the manifest file can use any suitable filename.

Recommended preparation

Install and test the application manually before writing the manifest. Record the topology, uploaded libraries, deployment paths, configuration-file changes and database operations that are required for a successful installation.

Mandatory Manifest Body

The basic manifest body identifies the JPS version, installation type and application definition.

{
  "jpsVersion": "0.2",
  "jpsType": "install",
  "application": { }
}

This part is mandatory. The install type indicates that a new environment should be created for application deployment. The application object is then extended with the application description and environment configuration.

Application Description

The application description contains the general information displayed to users during installation and in the Marketplace.

{
  "application": {
    "id": "myapp",
    "name": "My Application",
    "version": "1.0",
    "logo": "https://example.com/logo.png",
    "type": "java",
    "categories": ["apps/content-management"],
    "homepage": "https://example.com",
    "description": {
      "en": "Application description"
    },
    "startPage": "/",
    "success": {
      "text": "Application was deployed successfully.",
      "email": "Application installation has completed."
    }
  }
}
ValueDescriptionMandatory
idUnique application identifier. Lowercase values are recommended.Yes
nameApplication name displayed to users.Yes
versionApplication version.Yes
logoSecure HTTP link to the application logo.Yes
typeProgramming-language type, such as Java or PHP.Yes
categoriesMarketplace category or categories where the package should appear.No
homepageApplication homepage URL.Yes
descriptionUser-facing application description. It can be a string or a language-keyed object.Yes
startPageRelative page opened by the Open in Browser action. Defaults to /.No
successSuccess text shown in the dashboard and optionally sent by email.Yes

Marketplace Categories

Dev & Admin Toolsapps/dev-and-admin-tools
Clustersapps/clusters
Microservicesapps/microservices
Content Managementapps/content-management
E-Commerceapps/e-commerce
Storage & File Managerapps/file-manager
Project Managementapps/project-management

Multiple categories can be assigned to the same package. If no category is specified, the application can be placed in the default miscellaneous category.

Environment Configuration

The environment configuration defines the infrastructure and application setup that should be created during package installation. The main sections are:

  • TOPOLOGY — environment engine, nodes, High Availability and SSL.
  • UPLOAD — additional libraries, modules or files.
  • DEPLOYMENTS — application archives and deployment contexts.
  • CONFIGS — configuration-file changes and database operations.

TOPOLOGY Section

The topology object defines the programming-language engine, High Availability, SSL and node configuration required by the application.

"topology": {
  "ha": false,
  "engine": "java7",
  "ssl": true,
  "nodes": [ ]
}
NameDescriptionTypeExample ValuesMandatory
haHigh Availability setting.Booleantrue / falseYes
engineProgramming-language version.Stringjava6, java7, php5.3, php5.4, php5.5Yes
sslSSL enablement.Booleantrue / falseYes
nodesList of node definitions.ArraySee nodes subsection.No

NODES Subsection

"nodes": [
  {
    "extip": false,
    "count": 1,
    "cloudlets": 16,
    "nodeType": "tomcat7"
  }
]
NameDescriptionTypeMandatory
extipWhether an external/public IP is required.BooleanYes
countNumber of nodes to create.IntegerYes
cloudletsFlexible cloudlet allocation. Fixed and flexible values may also be defined separately.IntegerYes
nodeTypeSoftware stack or node template identifier.StringYes

Typical node types include application servers, web servers, databases, load balancers, Maven and caching services. Additional custom templates can also be used when they are integrated into the platform.

UPLOAD Section

Use the upload array when the application requires extra files such as libraries, drivers or modules to be downloaded and placed on specific nodes.

"upload": [
  {
    "nodeType": "tomcat7",
    "sourcePath": "https://example.com/jdbc-connector.jar",
    "destPath": "${WEBAPPS}/jdbc-connector.jar"
  }
]
NameDescriptionMandatory
nodeTypeNode where the file should be uploaded.Yes
sourcePathRemote URL of the file to download.Yes
destPathDestination path inside the target node.Yes

DEPLOYMENTS Section

The deployments array defines which application archive should be deployed and where it should be placed.

"deployments": [
  {
    "archive": "https://example.com/test.war",
    "name": "test.war",
    "context": "ROOT"
  }
]
NameDescriptionMandatory
archiveURL of the archive. Common formats include WAR, ZIP and TAR.GZ.Yes
nameName assigned to the deployed archive.Yes
contextDeployment context such as ROOT, / or another application path.Yes

CONFIGS Section

The configs array can modify configuration files on application servers, databases and other nodes. It can also restart nodes and perform database initialization or patching.

"configs": [
  {
    "nodeType": "tomcat7",
    "restart": true,
    "replacements": [ ],
    "path": "/path/to/config/file",
    "database": { }
  }
]
NameDescriptionMandatory
nodeTypeTarget node type for the configuration operation.No
restartWhether the node should be restarted after configuration.Yes
replacementsList of search-and-replace operations for the configuration file.No
pathPath to the configuration file used for replacements.No
databaseDatabase-creation, dump and patch settings.No

REPLACEMENTS Subsection

The replacements subsection searches for matching strings or regular expressions and replaces them with the required value. Platform placeholders can be used in the replacement text.

"replacements": [
  {
    "pattern": "app\\.host\\.url\\s*=\\s*.*",
    "replacement": "app.host.url = ${env.url}"
  }
]
patternRegular expression used to find the required configuration string.
replacementNew string written in place of the matched value. It can contain placeholders.

DATABASE Subsection

The database subsection can create the application database, optionally specify the database user, import an initial dump and execute a patch.

"database": {
  "name": "appdb",
  "user": "root",
  "dump": "https://example.com/appdb.sql",
  "patch": "UPDATE settings SET value='${user.email}' WHERE name='admin_email';"
}
NameDescriptionMandatory
nameName of the database to create.Yes
userDatabase user used by the application. If omitted, the root user can be used.No
dumpURL of an initial database dump.No
patchSQL query or URL to an SQL patch. Placeholder replacement can be used.No

Important Notes

  • Deploy and test the application manually before converting the installation into a package.
  • Keep the mandatory JPS body at the root of the manifest.
  • Use secure web URLs for logos, archives, libraries and database dumps.
  • Use placeholders for environment-specific values rather than hard-coding them.
  • Make sure the selected node types exist on the target platform.
  • Validate configuration replacements and database patches in a non-production environment first.