{
"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": {}
}
}
Introduction to Mule 4: Packaging Applications
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 |
---|---|
|
Descriptor for your Mule application (see Application Descriptor). |
|
An optional location for your source code. |
|
A repository for all your application’s dependencies in Maven layout. This includes all your connectors for your app. For example, |
|
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.
Application Descriptor Reference
Attribute | Value type | Description |
---|---|---|
|
Array of Strings |
Set of Mule configuration files. |
|
Boolean |
Whether modifying the app configuration files will trigger a redeployment. |
|
String |
Meaningful name for the app. |
|
String |
Minimum Mule Runtime version required to deploy the app. |
|
String |
Required product type to deploy the app. |
|
Object |
Descriptor of the classloading model for the app. The |
|
Object |
Descriptor of the app bundle coordinates. The |
|
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.
|