pom.xml file to ensure consistency, flexibility, and ease of management. These Maven properties help us to centralizing configuration values, so we don't have to hardcode them multiple times.Properties are defined within the
<properties> element. For example:<properties>
<your.property.key>your-property-value</your.property.key>
</properties>${your.property.key} syntax.Where can we define Maven Properties?
Maven properties can be defined in multiple places, not only the POM file. Here are the common places where we can define Maven properties:- POM File - Properties defined here are specific to the Mule project
- Parent POM - We can define properties in a parent POM. This way, these properties will be inherited by the child mule projects. That’s a very useful approach for centralization and standardization of our properties across our Mule apps.
- Settings.xml - The configuration file can use the maven properties using the same syntax. Normally, these properties would be global to the user or the machine. Properties in the settings files are particularly useful for credentials, environment-specific configurations, and user-specific values.
- Command Line - We can define the value of our properties using the Maven CLI with the syntax
-Dproperty=value. Property values coming from the command line will override the values defined in the POM. - Profiles - Maven properties can also be defined within Maven profiles, allowing us to change property values depending on the active profile (e.g., different environments like
dev,test,prod). - Environment Variables - System and environment variables can be used directly in Maven without defining them explicitly in the POM by using
${env.VAR_NAME}. For example, we would use this technique when using Github actions, as Github will set environment variables for the variables defined in the workflows.
What Properties can we define for our Mule Apps?
That sounds great but, what properties could we define for our Mule apps? Here are some ideas!1. Mule Runtime Version
This property specifies the version of the Mule runtime to be used across all Mule projects. This ensures that all projects are aligned on the same Mule version, preventing version conflicts.<properties>
<mule.runtime.version>4.4.0</mule.runtime.version>
</properties>2. Mule Maven Plugin Version
This property defines the version of the Mule Maven Plugin, which is responsible for building and deploying Mule applications. Centralizing this ensures that all projects use the same plugin version. This would be useful for this particular plugin. but if we wanted to take a more strategic/standardize approach we should use a BOM file and put in properties all the plugins/dependencies versions.<properties>
<mule.maven.plugin.version>3.7.1</mule.maven.plugin.version>
</properties>3. Mule API Version
For API projects, you can define the API version to maintain consistency across the different services and applications that may depend on or integrate with it.<properties>
<api.version>v1</api.version>
</properties>4. Anypoint Exchange and CloudHub Credentials
If we are deploying Mule applications using the Mule Maven Plugin, you may want to define properties for credentials. These can be referenced when configuring the Mule Maven Plugin or repository settings, so that we could take the values from the command line (via CI/CD or Build server). As mentioned earlier, the settings.xml would be the most suitable file to place these properties.<properties>
<anypoint.username>${env.ANYPOINT_USERNAME}</anypoint.username>
<anypoint.password>${env.ANYPOINT_PASSWORD}</anypoint.password>
</properties>5. Organization and Environment IDs
For Mule projects deploying to Anypoint Platform, it's common to specify the organization and environment IDs used for deployment. These properties can be referenced in the Mule Maven Plugin for consistent deployment configuration. Here's an example for the configuration of the Mule Maven Plugin to deploy to cloudhub 2.0<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
...
<configuration>
...
<cloudhub2Deployment>
...
<businessGroupId>${env.MULE_BG_ID}</businessGroupId>
<environment>${env.environment}</environment>
...
</cloudhub2Deployment>
...
</plugin>
6. Anypoint Platform Deployment Properties
You might want to define deployment properties for Mule applications, especially when deploying to CloudHub or using Runtime Manager.Parameters that we need to provide in the cloudhub2 or runtime fabric plugins deployment like number of replicas, worker size, environment...
<properties>
<anypoint.client.id>${env.ANYPOINT_CLIENT_ID}</anypoint.client.id>
<anypoint.client.secret>${env.ANYPOINT_CLIENT_SECRET}</anypoint.client.secret>
<deploy.target>dev</deploy.target>
<cloudhub.workers>2</cloudhub.workers>
<cloudhub.worker.type>Micro</cloudhub.worker.type>
<cloudhub.region>us-east-1</cloudhub.region>
<cloudhub.domain>.us-w2.cloudhub.io</cloudhub.domain>
<ch.deploymentTimeout>300000</ch.deploymentTimeout>
</properties>7. API Manager Configuration Properties
For API projects, we can define properties that control how the APIs are managed and published to Anypoint API Manager.<properties>
<api.manager.application.name>MyAPI</api.manager.application.name>
<api.manager.version>${api.version}</api.manager.version>
<api.manager.autodiscoveryId>12345</api.manager.autodiscoveryId>
<anypoint.platform.client_id>${env.client_id}</anypoint.platform.client_id>
<anypoint.platform.client_secret>${env.client_secret}</anypoint.platform.client_secret>
</properties>8. Profile-Specific Properties for Different Build Profiles
For projects that need different settings based on environments like development, QA, or production, you can define common properties for different environments. These properties can be referenced within Maven profiles that target different environments.<profiles>
<profile>
<id>dev</id>
<properties>
<environment>development</environment>
<db.url>jdbc:mysql://dev-db.example.com:3306/dev</db.url>
<db.username>devuser</db.username>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<environment>production</environment>
<db.url>jdbc:mysql://prod-db.example.com:3306/prod</db.url>
<db.username>produser</db.username>
</properties>
</profile>
</profiles>9. Analytics and Visualizer Properties
From the POM file we can define runtime properties via the Mule Maven Plugin. 3 interesting runtime properties are- the enablement of the agent to collect metrics from the app
- For the Visualizer, we can define a property for the display name of the app in Visualizer and the API layer that would be assigned to each app. That would make our app to be placed in the corresponding layer in our Visualizer view.
<properties>
<anypoint.platform.config.analytics.agent.enabled>true</anypoint.platform.config.analytics.agent.enabled>
<anypoint.platform.visualizer.displayName>${project.name}</anypoint.platform.visualizer.displayName>
<anypoint.platform.visualizer.layer>${env.api_layer}</anypoint.platform.visualizer.layer>
</properties>10. Private Repositories Properties
If our organization uses a custom Maven repository (e.g., Nexus, Artifactory), we can define the repository URLs and the credentials as properties. These properties are good candidates for the settings.xml file. Notice in the example below that the properties for the Nexus credentials would be provided as environment variables.<properties>
<nexus.repo.url>https://nexus.example.com/repository/maven-releases/</maven.repo.url>
<nexus.username>${env.nexus_username}</nexus.username>
<nexus.password>${env.nexus_pass}</nexus.password>
</properties>11. Log4j configuration
As we’ve seen in this post, using Maven Resource Filtering we can use maven properties in the log4j2.xml file. So, for example, we could include the configuration of our log appender(s) in the settings.xml<properties>
<splunk.url>https://mysplunk.com:8088/<splunk.url>
<splunk.token>8de4251a-00de-4416-895d-2856a520d26f</splunk.token>
<splunk.index>mule_logs</splunk.index>
</properties>12. Shared Libraries or External Libraries Versions
If you are using external libraries or shared libraries across multiple projects, you can centralize their versions to ensure consistency.<properties>
<commons.lang.version>3.12.0</commons.lang.version>
<jackson.version>2.11.3</jackson.version>
<log4j.version>2.17.0</log4j.version>
</properties>13. Artifact Naming Properties
We can control the naming conventions of our final build artifacts (e.g., JAR or Mule archive files) using properties.<properties>
<final.artifact.name>${project.artifactId}-${project.version}.jar</final.artifact.name>
<final.archive.name>${project.artifactId}-${project.version}.jar</final.archive.name>
</properties>final.artifact.name: Defines how the final artifact (such as JAR) is named after the build process.final.archive.name: Can be used to name the Mule application's final deployment archive (e.g.,.jar,.zip).
14. Project Documentation and Metadata
You might want to include project metadata like the project description, URL, and organization info to ensure it is consistent across projects.<properties>
<project.description>This is a MuleSoft integration project.</project.description>
<project.url>https://github.com/example/mulesoft-project</project.url>
<organization.name>Example Corp</organization.name>
<organization.url>https://www.example.com</organization.url>
</properties>project.description: A description of the project, useful in metadata when sharing artifacts in repositories.project.url: The project’s URL (e.g., for a GitHub repository).organization.name: The name of the organization responsible for the project.organization.url: The organization's URL.
15. Maven Resource Filtering
You can define properties that enable Maven resource filtering, which allows for placeholders in configuration files (e.g.,*.properties, *.xml) to be replaced with values during the build process.<properties>
<resource.filtering>true</resource.filtering>
<config.environment>${env}</config.environment>
</properties>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>${resource.filtering}</filtering>
</resource>
</resources>
</build>resource.filtering: Enables filtering to replace placeholders in resource files with Maven properties.config.environment: Can dynamically set the environment in configuration files.