Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (4.1)
  3. Mule 4 for Mule 3 Users
  4. Mule 4

  5. Packaging Applications

Introduction to Mule 4: Packaging Applications

Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended.

Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.

MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.

Application Structure

There are few important changes to how Mule applications are packaged in Mule 4. Mule applications are now packaged as a JAR and have a different structure. You can use the Mule Maven Plugin to easily package your source code into this structure.

Location Description

META-INF/mule-artifact/mule-artifact.json

Descriptor for your Mule application (see Application Descriptor).

META-INF/mule-src/yourapp/

An optional location for your source code.

repository

A repository for all your application’s dependencies in Maven layout. This includes all your connectors for your app. For example, repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar

yourapp.xml

Your Mule XML code.

Application Descriptor

Mule 4 applications include a mule-artifact.json file in META-INF/mule-artifact/. This describes your app, configuration settings, the required Mule version, and the class loader configuration.

{
  "configs": [
    "ch-usage-sync.xml"
  ],
  "redeploymentEnabled": true,
  "name": "ch-usage-sync",
  "minMuleVersion": "4.0.0",
  "requiredProduct": "MULE_EE",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedResources": []
    }
  },
  "bundleDescriptorLoader": {
    "id": "mule",
    "attributes": {}
  }
}

Application Descriptor Reference

Attribute Value type Description

configs

Array of Strings

Set of Mule configuration files.

redeploymentEnabled

Boolean

Whether modifying the app configuration files will trigger a redeployment.

name

String

Meaningful name for the app.

minMuleVersion

String

Minimum Mule Runtime version required to deploy the app.

requiredProduct

String

Required product type to deploy the app. MULE means that the app can be deployed on the Community Edition (CE) version or the Enterprise Edition (EE) version. MULE_EE means that the app can only be deployed on the EE version.

classLoaderModelLoaderDescriptor

Object

Descriptor of the classloading model for the app. The id field identifies the mechanism to be used by the runtime to understand how the dependencies and the packages/resources of the app are meant to be used. By default, Mule uses the ID mule, which means that the exported packages and resources from the apps are described in the attributes field, and the dependencies are described in the file /META-INF/mule-artifact/classloader-model.json.

bundleDescriptorLoader

Object

Descriptor of the app bundle coordinates. The id field identifies the mechanism to be used by the runtime to understand the app bundle coordinates. The default is mule and will load the Artifact Group ID, Artifact ID, and Version from the POM file.

secureProperties

Array of Strings

Declares the set of configuration properties of the artifact that must be managed as secure in the platform.

Application Versioning

Mule Runtime follows semantic versioning in all its artifacts. By following semantic versioning, clients of our APIs can clearly understand what to expect whenever MuleSoft releases a new version of an asset. For instance, consider the case of Mule connectors. You can expect bug fixes (and only bug fixes) when a patch version is updated. You can expect new features in new minor versions. Both of those changes are expected to be backward compatible so that you can upgrade without any problem. But if MuleSoft updates the major version of the connector, it means that it was necessary to break backward compatibility to include new functionality or provide a much better UX.

It is also expected that Mule artifacts (app, domains, policies) follow semantic versioning, so you might encounter some validations when working with Mule apps. By following semantic versioning, Anypoint Platform can better understand new assets and provide a better experience. For instance, if there’s a new major version of a Mule domain, you can expect that there is not going to be, for instance, the same set of global components defined in it as in the previous major version. So mule apps that belong to that domain might required to be updated if the new domain is used.

Mule Maven Plugin

The Mule Maven Plugin in Mule 4 packages your app into the required format and enables you to deploy it into your target environment. Studio 7 will automatically add the plugin to your pom.xml. See the Mule Maven Plugin documentation for information on how to use it to deploy apps.

Domains, policies, Mule artifact plugins (connectors, modules, and so on) all have the same structure as Mule apps. Depending on the type of artifact, there might be more or less properties in the artifact descriptors (mule-artifact.json), but they are all similar and all must follow semantic versioning.

See Also