Configuring the Sonatype Nexus repository to proxy Maven artifacts
Good day!
About the build utility for Maven Java projects and about the possibility of creating a local server for the Maven repository using Sonatype Nexus on Habré have already been mentioned ( here and here ). However, no recipe was provided on this subject. This is not surprising in the presence of sufficiently complete competent documentation . As a result of my service, I had to set it up at our company, and it turned out that the tips from the official documentation did not quite fit. I want to share the problem and the way to solve it with the community. But first things first.
A local server for the Maven repository (such as Sonatype Nexus) can be used to store local Maven artifacts, and really will be useful to teams that develop modular applications, but are not going to publish modules to the public.
In addition, such a server can also work for local storage of remote Maven artifacts, which significantly reduces the loading time of remote artifacts by all team members and prevents external repositories from being inaccessible. It is about such use that we will discuss further.
There are three most popular such servers:
At this stage, you can safely follow the documentation, in my memory there were no problems. The Sonatype website has a good training screencast . I will briefly explain the essence of the installation process.
There are 2 ways to deploy Nexus:
In principle, it can already be used without any configuration (Maven central, Codehaus, Apache proxy repositories are available out of the box), but it makes sense to configure access rights, repository groups, add the necessary proxy repositories, enable indexing, etc.
This stage is already much more ambiguous. Let's see what the official documentation offers us .
Here it is recommended to write the following in settings.xml:
At the same time, they honestly say that such a setting can cause problems if third-party repositories are defined in the pom.xml using the tag
It is logical advice, but there are a number of organizational problems associated with restricting access to Nexus administration. So, for example, in order to try a third-party library in business, the developer is forced to pull the admin to add the appropriate repository to Nexus. For a while, turn off this mirror in settings.xml - that’s another crutch.
What other options can I use to overcome this problem? The following 3 come to mind:
In essence, with this setting we add a profile, active by default, which adds Nexus as a regular repository. And he is added first to the queue.
Now all requests are first sent to Nexus. Depending on the availability of the requested artifact in the stored and connected proxy repositories, the latter either returns the requested artifact or responds negatively. If the answer is no, Maven will simply continue to poll the repositories listed in pom.xml and then turn to the Maven central repository.
Only one drawback was revealed - there is a danger of forgetting to add the necessary additional repository to pom.xml. True, it should be noted that this drawback applies to virtually all approaches (except the 2nd) and can also occur in the absence of a local Nexus repository.
The fact is that if a third-party repository is added to Nexus, then for developers who have Nexus connected, the assembly will work without problems. But developers, without Nexus configured, will not be able to build the project at all, since their Maven will not know from which additional repository you need to request artifacts.
A similar situation may arise simply if some artifact is cached in the local developer repositories after working on previous projects. In general, in this matter it is only important not to lose vigilance.
I must say that the advice of the authors of the documentation to add all the additional repositories described in pom.xml projects has not been canceled in Nexus. This is really best done in order to benefit from the use of a proxy Maven repository. But on the other hand, the application of the proposed solution makes it optional, which can take away the developer’s waiting time until the admin adds the necessary repository.
UPD: I came across an interesting article that addresses similar issues.
About the build utility for Maven Java projects and about the possibility of creating a local server for the Maven repository using Sonatype Nexus on Habré have already been mentioned ( here and here ). However, no recipe was provided on this subject. This is not surprising in the presence of sufficiently complete competent documentation . As a result of my service, I had to set it up at our company, and it turned out that the tips from the official documentation did not quite fit. I want to share the problem and the way to solve it with the community. But first things first.
Why is this needed?
A local server for the Maven repository (such as Sonatype Nexus) can be used to store local Maven artifacts, and really will be useful to teams that develop modular applications, but are not going to publish modules to the public.
In addition, such a server can also work for local storage of remote Maven artifacts, which significantly reduces the loading time of remote artifacts by all team members and prevents external repositories from being inaccessible. It is about such use that we will discuss further.
There are three most popular such servers:
- Sonatype nexus
- Apache archiva
- Artifactory
Install Sonatype Nexus
At this stage, you can safely follow the documentation, in my memory there were no problems. The Sonatype website has a good training screencast . I will briefly explain the essence of the installation process.
There are 2 ways to deploy Nexus:
- as a WAR file on any container (e.g. Apache Tomcat)
- unzip the archive and run it manually (using Jetty inside). The default port is 8081. URL: http: // host: 8081 / nexus
In principle, it can already be used without any configuration (Maven central, Codehaus, Apache proxy repositories are available out of the box), but it makes sense to configure access rights, repository groups, add the necessary proxy repositories, enable indexing, etc.
Configuring Maven to Use Sonatype Nexus as a Proxy
This stage is already much more ambiguous. Let's see what the official documentation offers us .
Here it is recommended to write the following in settings.xml:
<mirror>
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<url>http://host:8081/nexus/content/groups/public</url>
</mirror>
* This source code was highlighted with Source Code Highlighter.At the same time, they honestly say that such a setting can cause problems if third-party repositories are defined in the pom.xml using the tag
<repositories>. The fact is that with this setup, Maven only polls Nexus, which may not be aware of the presence of additional repositories. It just so happened that our project has such repositories. The documentation advises in such situations to add all such repositories to the public group of the local repository.It is logical advice, but there are a number of organizational problems associated with restricting access to Nexus administration. So, for example, in order to try a third-party library in business, the developer is forced to pull the admin to add the appropriate repository to Nexus. For a while, turn off this mirror in settings.xml - that’s another crutch.
What other options can I use to overcome this problem? The following 3 come to mind:
- Use mirror with option
<mirrorOf>central</mirrorOf>.
Everything works, but the benefits in performance and in saving traffic from using the mirror are few. In this case, Nexus will proxy only the main repository, since all additional repositories are polled earlier than central. - Add Nexus as a repository to each project in pom.xml. This option is even less convenient, besides it is not suitable, for example, for other people's and public projects (when it is impossible to make changes to pom.xml). But the Nexus_a poll can be done first in the queue.
- Add Nexus as a repository to your default profile. This is an approach that combines the positive features of the above - centralized configuration and efficient proxying
<profiles>
<profile>
<id>nexus</id>
<repositories>
<repository>
<id>nexus-repo</id>
<name>Nexus repo</name>
<url>http://host:8081/nexus/content/groups/public</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>nexus-repo</id>
<name>Nexus repo </name>
<url>http://host:8081/nexus/content/groups/public</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>nexus</activeProfile>
</activeProfiles>
* This source code was highlighted with Source Code Highlighter.In essence, with this setting we add a profile, active by default, which adds Nexus as a regular repository. And he is added first to the queue.
Now all requests are first sent to Nexus. Depending on the availability of the requested artifact in the stored and connected proxy repositories, the latter either returns the requested artifact or responds negatively. If the answer is no, Maven will simply continue to poll the repositories listed in pom.xml and then turn to the Maven central repository.
Benefits of the Approach
- Configurable in one place, once for all projects;
- acceleration of access to artifacts from all repositories registered in Nexus (including for additional repositories);
- assembly performance is not broken if the external repository described in pom.xml is not registered in Nexus;
- the ability to temporarily disable the use of Nexus (
mvn -P !nexus).
mvn -s filepath), but this does not seem to me an elegant solution.Disadvantages of the approach
Only one drawback was revealed - there is a danger of forgetting to add the necessary additional repository to pom.xml. True, it should be noted that this drawback applies to virtually all approaches (except the 2nd) and can also occur in the absence of a local Nexus repository.
The fact is that if a third-party repository is added to Nexus, then for developers who have Nexus connected, the assembly will work without problems. But developers, without Nexus configured, will not be able to build the project at all, since their Maven will not know from which additional repository you need to request artifacts.
A similar situation may arise simply if some artifact is cached in the local developer repositories after working on previous projects. In general, in this matter it is only important not to lose vigilance.
Afterword
I must say that the advice of the authors of the documentation to add all the additional repositories described in pom.xml projects has not been canceled in Nexus. This is really best done in order to benefit from the use of a proxy Maven repository. But on the other hand, the application of the proposed solution makes it optional, which can take away the developer’s waiting time until the admin adds the necessary repository.
UPD: I came across an interesting article that addresses similar issues.