How to create a Private Nexus Repository for Mule

In our previous post, we learnt How to use a Maven Private Repository for our Mule Apps where we were using the three types of maven repositories - hosted, proxy and group maven repositories. In this post, we'll see, step by step, how to put that strategy in practice on Nexus.

Prerequisites

We’ll start from a Nexus instance installed in our local network. If you still don’t have a Nexus instance, have a look at this post on How to install Nexus on Docker so that you can get your Nexus instance in 10 minutes.

Our local Nexus instance will be running on http://localhost:8081

Create a Hosted Repository for our Mule releases

This will be our private vault for released Mule application artifacts such as our Mule apps.

Go to Repositories → Create repository → choose maven2 (hosted).
Repository ID: mule-releases.
Version policy: Release.
Write policy: Allow redeploy or Disable redeploy (we prefer Disable redeploy for strict governance; snapshots use a separate repo).
Storage location: default.
Save.

This is the repo where our developers in Anypoint Studio or CI Servers will be publishing the builds (JARs) of our Mule apps so it will require write permissions on this. For security reasons, it’s important that we limit access to this repo to only authorized users. For that we could create roles and users in Nexus. Have a look at the previous post on How to publish Mule artifacts to Nexus Repository to see an example.

Create Proxy Repositories

Now we’ll create a proxy for each public repository that our mule apps might need

Proxy Repository for Maven Central

Mule apps depend heavily on Java libraries. These do not live in MuleSoft repositories. This is where we’ll cache the java-related public artifacts such as jackson libraries, log4j libraries or apache commons IO

Go to Repositories → Create repository → choose maven2 (proxy).
ID: mule-maven-central.
Remote storage URL: https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee.
Version policy: Release.
Layout policy: Permissive
Strict Content Validation: Don’t enable the MIME Validation
Remote authentication: none (unless your remote requires it).
Save.

Proxy Repository for Mulesoft Public

The Mulesoft Public Repository contains publicly available MuleSoft connectors and modules. For example the HTTP connector, the File connector or the Validation Module.

Create repository → maven2 (proxy).
ID: mule-public.
Remote storage URL: https://repository.mulesoft.org/releases/.
Version policy: Release.
Layout policy: Permissive
Strict Content Validation: Don’t enable the MIME Validation
Save.

Proxy Repository for the Mulesoft Enterprise Repository

The MuleSoft Enterprise Repository allows you to access Mule Enterprise modules, connectors, and other components not included in the trial or community versions. These are licensed MuleSoft enterprise assets used by organizations with a Mule Enterprise license. For example MUnit or Object Store. The Mulesoft Enterprise Repository requires credentials, only available for Mulesoft customers.

Create repository → maven2 (proxy).
ID: mule-enterprise.
Remote storage URL: https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee.
Version policy: Release.
In HTTP Settings (or Remote storage Authentication) set the username and password used to access that protected remote repo. (This stores the remote credentials in Nexus.). This way, when the remote needs credentials, Nexus handles them. We do not expose the remote password in every developer environment.
Save.

Proxy Repository for Anypoint Exchange

Anypoint Exchange is also built on a public Maven repository so we also need to proxy this one. In Exchange, for example, we can find many connectors like Salesforce, Database or SAP as well as the Mulesoft Accelerators.

Create repository → maven2 (proxy).
ID: mule-exchange.
Remote storage URL: https://maven.anypoint.mulesoft.com/api/v3/maven
Save.

Create Group Repository

Once we’ve defined all the private repositories necessary now we’ll create a Group Repo to consolidate all of them under a single endpoint. This way we only have to provide a unique URL for our developers in Anypoint Studio or our CI Servers.

Create repository → maven2 (group).
ID: mule-group.
Name: Mule Group (hosted + proxies).
Add members in this order (order matters for resolution):

mule-releases (hosted)
mule-enterprise (proxy)
mule-public (proxy)
mule-exchange (proxy)
mule-maven-central (proxy)

5. Save. With that our unique Group URL to access all the private repos we defined will be http://localhost:8081/repository/mule-releases/

Create a Mule App to use the Private Repository

Now it’s time to test our private repo. For that, we’ll create a simple Mule app and modify its settings so that it only uses our Private repos to download all the artifacts and publish the the JAR of the app also to our private repo.
For that, create a new project...

Modify the POM file

First we’ll provide the maven coordinates for our Mule app. These will be the coordinates that will identify this artifact in our Nexus repository:

groupId - Typically we use the reverse internal domain name (com.mycompany)
artifactId - The name of the mule app
version - We will use 1.0.0 (remove the SNAPSHOT, our Nexus repository is only for Releases)
packaging - In this example we will use a mule-application

<groupId>com.demos.gon</groupId>
<artifactId>hello-nexus</artifactId>
<version>1.0.0</version>
<packaging>mule-application</packaging>

In the POM file of our test app we need to remove all references to a repository. This way, we’ll force our app to use only the repositories configured in the settings.xml of the maven environment. By default, Anypoint Studio adds the Mulesoft public repositories. Make sure you remove the whole repositories and pluginRepositores sections from the pom file:

<project>
    ...
    <repositories>
        <repository>
            <id>anypoint-exchange-v3</id>
            <name>Anypoint Exchange</name>
            <url>https://maven.anypoint.mulesoft.com/api/v3/maven</url>
            <layout>default</layout>
        </repository>
        <repository>
            <id>mulesoft-releases</id>
            <name>MuleSoft Releases Repository</name>
            <url>https://repository.mulesoft.org/releases/</url>
            <layout>default</layout>
        </repository>
    </repositories>
    
    <pluginRepositories>
        <pluginRepository>
            <id>mulesoft-releases</id>
            <name>MuleSoft Releases Repository</name>
            <layout>default</layout>
            <url>https://repository.mulesoft.org/releases/</url>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </pluginRepository>
    </pluginRepositories>
    ...
</project>

On the other hand, to publish the build artifact of this app to our private repo we’ll need to add our Private Hosted repo within the distributionManagement tag:

<project>
    ...
    <distributionManagement>
        <repository>
            <id>mule-releases</id>
            <name>Mule Nexus Repo</name>
            <url>http://localhost:8081/repository/mule-releases/</url>
        </repository>
    </distributionManagement>
    ...
</project>

Here we won’t specify the credentials to the hosted repo, that will go into the settings.xml file.

Modify the settings.xml file

<settings>
    <mirrors>
        <!-- Mirror everything to our Nexus group repo -->
        <mirror>
            <id>mule-group</id>
            <name>Internal Nexus Mule Public Group</name>
            <url>http://localhost:8081/repository/mule-group/</url>
            <mirrorOf>*</mirrorOf>
        </mirror>
    </mirrors>
    <servers>
        <!-- Credentials for deploying to hosted repo mule-releases -->
        <server>
            <id>mule-releases</id>
            <username>ci-deploy-user</username>
            <password>Mule1234</password>
        </server>
    </servers>
</settings>

Important:

mirrorOf = * forces Maven to ask only mule-group for dependencies.
server IDs must match distributionManagement repository ids in the pom.xml (mule-releases, mule-snapshots).
Use secure credential injection in CI. Do not commit passwords into source control.

Test

With all of this configuration, our Maven setup should read only from our Private repos:

Maven sends all requests for dependencies to the mirror URL http://localhost:8081/repository/mule-group/.
Nexus mule-group checks its member repos in order.
If mule-releases has the artifact, it returns it.
If not, Nexus fetches from the appropriate proxy (for example mulesoft-enterprise or maven-central), caches it, and returns it.
This gives us a single controlled source. Developers never contact the public internet directly. Builds are fast and predictable.

Let’s test it. Let’s build and publish our Mule app. From the project root folder open a terminal and run:

mvn clean deploy

Maven builds the Mule application and sends the artifact to the distributionManagement repository mule-releases.
Nexus receives the artifact and stores it in mule-releases. It becomes available from the mule-group endpoint.

Verify artifact is in Nexus

In Nexus UI go to Browse → Repositories → choose mule-releases.
Search for the coordinates of your test app.
You should see the component and files.
From any other machine, request http://localhost:8081/repository/mule-group/com/example/hello-nexus/1.0.0/hello-nexus-1.0.0.zip (or artifact extension). Nexus will serve it.

How to create a Private Nexus Repository for Mule - Step by Step