Introduction to Mule 4: Packaging Applications | MuleSoft Documentation
# 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  
---|---  
`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  
---|---|---  
Array of Strings | Set of Mule configuration files.  
`redeploymentEnabled` | Whether modifying the app configuration files will trigger a redeployment.  
Meaningful name for the app.  
`minMuleVersion` | Minimum Mule Runtime version required to deploy the app.  
`requiredProduct` | 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` | 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` | 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
  * Package Mule Apps using the Mule Maven Plugin
  * Deploy Mule Apps using the Mule Maven Plugin