This guide outlines the steps to publish custom policies to the Private Cloud Edition (PCE) Exchange, including a workaround for common ArtifactNotFoundException errors.
MuleSoft Documentation reference - https://docs.mulesoft.com/private-cloud/latest/custom-policies
When publishing custom policies to PCE Exchange using Maven, the following error may occur:
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException:
Could not find artifact
608c0809-d459-442f-92c8-e015491c3755:beta10-testing:pom:1.0.1 in
exchange-server
(https://pce41-8node-26e658a2edf83013.elb.us-east-2.amazonaws.com
/exchange/api/v2/organizations/608c0809-d459-442f-92c8-e015491c3755/maven)
Sample screenshot for reference :
This ArtifactNotFoundException indicated a challenge with how Maven was locating or pushing artifacts to the Exchange's Maven repository.
To resolve this issue, follow these key steps:
Update the mule-maven-plugin version: Ensuring a modern and compatible version of the plugin.
Specific Connected App Permissions: Configuring a Connected App with precisely the necessary Exchange permissions, avoiding overly broad access.
Using a Specific Maven Version: Standardizing local Maven environment to a version that proved compatible with the deployment.
Here are the detailed steps should be followed to get the custom policies published to PCE Exchange.
Anypoint Platform Account: With access to your PCE instance.
Maven: Specifically, use version 3.9.6 installed on your local machine.
Java Development Kit (JDK): Java Version 8 or higher.
MuleSoft Anypoint Studio (Optional): While not strictly required for the deployment itself, it's useful for policy development and local testing.
To authenticate via Maven deployment with Anypoint Platform Exchange, we need to craete a Connected App.
Log in to Anypoint Platform: Please access to your PCE instance.
Navigated to Access Management: Access Management > Connected Apps.
Created a New App: Click on Create App.
Configured the App Details:
App Name: give a clear name like PCE-Exchange-Policy-Publisher.
App Type: select Client Credentials.
Grant Type: choose Client Credentials.
Scopes (This was crucial!):
Under Exchange, grant Exchange Contributor permissions.
Under Exchange, grant Exchange Viewer permissions.
Important: deliberately avoided selecting General Admin scopes or other excessively broad permissions. In our testing showed that focused Exchange-specific permissions were sufficient and worked without issues.
Saved the App: After adding the scopes, click Save.
Recorded Credentials: Immediately after saving, copy the Client ID and Client Secret. Please copy the credentials as we needed them for Maven settings.xml file.
We need to add a server entry to the Maven settings.xml file, using the credentials from the Connected App.
Located settings.xml: You will find the file at ~/.m2/settings.xml (on macOS/Linux; for Windows, it's %USERPROFILE%\.m2\settings.xml). If it didn't exist, please create it.
Added the Server Entry: Insert the following server block within the <servers> section of the settings.xml. Please make sure to replace YOUR_CLIENT_ID and YOUR_CLIENT_SECRET with the actual credentials that copied from Connected App.
With Username and Password combination
<settings>
<servers>
<server>
<id>exchange-server</id>
<username>YOUR_CLIENT_ID</username>
<password>YOUR_CLIENT_SECRET</password>
</server>
</servers>
</settings>
With Client Connected app combination
<settings>
<servers>
<server>
<id>exchange-server</id>
<username>~~~Client~~~</username>
<password>YOUR_CLIENT_SECRET</password>
</server>
</servers>
</settings>
The <id>exchange-server</id> is important; it must match the repository ID that's typically defined in the policy's pom.xml for Exchange deployments.
The username and password here correspond to the Connected App's Client ID and Client Secret, enabling authentication.
Use the following command to generate a custom policy project:
keytool -printcert -sslserver ${ANYPOINT_DNS}:443 -rfc > /tmp/anypoint.crt
keytool -importcert -alias my-company.com -keystore
/etc/ssl/certs/java/cacerts -storepass changeit -file /tmp/anypoint.crt
Whether starting a new project or working with an existing one, please ensure its pom.xml was correctly configured.
Project Creation (if new): If you were starting fresh, please use the Mule custom policy archetype:
Bash:
mvn -Parchetype-repository archetype:generate \ -DarchetypeGroupId=org.mule.tools \ -DarchetypeArtifactId=api-gateway-custom-policy-archetype \ -DarchetypeVersion=1.0.0 \ -DgroupId=${orgId} \ -DartifactId=${policyName} \ -Dversion=1.0.0-SNAPSHOT \ -Dpackage=mule-policy
Then follow the prompts to set your groupId, artifactId, version, etc.
Update the pom.xml: Open the pom.xml file of custom policy project.
Critical Update: Please make sure to update the mule-maven-plugin version. The version 4.5.1 will work reliably. Locate the plugin entry within the <build><plugins> section and update its version:
XML:
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
<version>4.5.1</version>
<extensions>true</extensions>
<configuration>
<skipDeploy>false</skipDeploy>
</configuration>
</plugin>
Repository Configuration Check: Verify that the distributionManagement section in pom.xml correctly pointed to the Exchange repository with the exchange-server ID. The archetype usually sets this up correctly:
<distributionManagement>
<repository>
<id>exchange-server</id>
<name>Exchange Repository</name>
<url>
https://pce41-8node-26e658a2edf83013.elb.us-east-2.amazonaws.com/exchange/api/v2/organizations/${project.organizationId}/maven
</url>
</repository>
</distributionManagement>
The ${project.organizationId} placeholder is resolved from policy's properties or passed via Maven.
This step was a key part of the workaround. Maven version 3.9.6 was crucial for successful deployment.
mvn -v
Installed Maven 3.9.6+ (if necessary): If your version was different, download Maven 3.9.6 from the Apache Maven Archive and updated PATH environment variable to point to its bin directory.
With all the configurations in place, proceed with the deployment.
Navigated to Project Directory: In terminal, navigate to the root directory of custom policy project (where pom.xml is located).
Run the Maven Deploy Command:
Bash:
mvn clean deploy -Dmule.deploy.organizationId=
Replace <OUR_ORGANIZATION_ID> with your actual Anypoint Platform Organization ID (found under Access Management > Organization in Anypoint Platform).
The clean deploy command handles compilation, packaging, and deployment to the configured PCE Exchange repository. The -Dmule.deploy.organizationId property is vital for the mule-maven-plugin to target the correct organization within Exchange.
Verified Deployment:
Upon successful completion, you will see BUILD SUCCESS in terminal.
Finally, navigat to Anypoint Platform > Exchange within PCE instance. The published custom policy will be listed there, confirming its successful publication and readiness for use.
Login to PCE Environment and navigate to Exchange and validate the deployment
ArtifactNotFoundException: As noted, this was successfully resolved by ensuring the correct mule-maven-plugin version, precise Connected App permissions, and a Maven version (3.9.6+).
Connected App Permissions: The granular permissions (Exchange Contributor, Exchange Viewer) were more effective than overly broad ones like General Admin.
Maven Version Compatibility: The specific compatibility between the mule-maven-plugin and Maven versions played a significant role. The version 3.9.6 is a crucial takeaway.
PCE Exchange URL: Always double-check that the repository URL in pom.xml accurately points to your PCE instance's Exchange Maven endpoint.
005103352

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.