Setting up the Sonatype Nexus repository for proxying 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é has already been mentioned ( here and here ). However, no recipe on this was presented. This is not surprising in the presence of fairly complete competent documentation . On duty, I had to customize it in our company, and it turned out that the advice from the official documentation is not quite suitable. I want to share the emerging problem and the way to solve it with the community. But first things first.
The local server for the Maven repository (like Sonatype Nexus, for example) can be used to store local Maven artifacts, and is really useful for teams that develop modular applications, but are not going to publish the modules to the public.
')
In addition, such a server can also work for local storage of remote Maven artifacts, which significantly reduces the load time for remote artifacts by all team members and prevents the external repositories from being inaccessible. It is about this use and will be discussed further.
There are three most popular such servers:
At this stage, you can safely follow the documentation, in my memory there were no problems. On the Sonatype website there is a good learning screencast . Briefly retell the essence of the installation process.
There are 2 ways to deploy Nexus:
In principle, they can already be used without any configuration (Maven central, Codehaus, Apache proxy repositories are available from the box), but it makes sense to set up access rights, repository groups, add the necessary proxy repositories, enable indexing, etc.
This stage is 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 for the project in pom.xml using the
It is quite logical advice, but there are a number of organizational problems associated with restricting access to the administration of Nexus. For example, in order to try a third-party library in practice, the developer is forced to pull the admin to add the corresponding repository to Nexus. For the time being, turning off this mirror in settings.xml is one more crutch.
What other options can be used to overcome the problem described? The following 3 come to mind:
In fact, with this setting we add a default profile, which adds Nexus as a normal repository. And it is added first to the queue.
Now all requests are first sent to Nexus_y. That, depending on the presence of the requested artifact in the stored and connected proxy repositories, either gives 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 refer to the Maven central repository.
Only one drawback has been identified - there is a danger of forgetting to add the necessary additional repository in pom.xml. However, it should be noted that this disadvantage concerns virtually all approaches (except the 2nd) and can also manifest itself in general 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 a Nexus connected, the build will take place without problems. But developers, without a customized Nexus, will not be able to build a project at all, since Maven will not know from which additional repository 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 the pom.xml projects, in Nexus has not been canceled. This is really best done in order to get the benefit of using a proxying Maven repository. But the application of the proposed solution makes it unnecessary, which can remove the developer’s waiting time until the admin adds the required repository.
UPD: I stumbled upon 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é has already been mentioned ( here and here ). However, no recipe on this was presented. This is not surprising in the presence of fairly complete competent documentation . On duty, I had to customize it in our company, and it turned out that the advice from the official documentation is not quite suitable. I want to share the emerging problem and the way to solve it with the community. But first things first.
Why do you need it?
The local server for the Maven repository (like Sonatype Nexus, for example) can be used to store local Maven artifacts, and is really useful for teams that develop modular applications, but are not going to publish the modules to the public.
')
In addition, such a server can also work for local storage of remote Maven artifacts, which significantly reduces the load time for remote artifacts by all team members and prevents the external repositories from being inaccessible. It is about this use and will be discussed further.
There are three most popular such servers:
- Sonatype nexus
- Apache archiva
- Artifactory
Sonatype Nexus Installation
At this stage, you can safely follow the documentation, in my memory there were no problems. On the Sonatype website there is a good learning screencast . Briefly retell the essence of the installation process.
There are 2 ways to deploy Nexus:
- as a WAR file on any container (for example, Apache Tomcat)
- unpack the archive and run it manually (Jetty is used inside). The default port is 8081. URL: http: // host: 8081 / nexus
In principle, they can already be used without any configuration (Maven central, Codehaus, Apache proxy repositories are available from the box), but it makes sense to set up access rights, repository groups, add the necessary proxy repositories, enable indexing, etc.
Configuring Maven to use Sonatype Nexus as a proxy
This stage is 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 for the project in pom.xml using the
<repositories> . The fact is that with this setup, Maven polls only Nexus, which may not be aware of the availability of additional repositories. It so happens that in our project such repositories are available. Documentation advises in such situations to add all such repositories to the public group of the local repository.It is quite logical advice, but there are a number of organizational problems associated with restricting access to the administration of Nexus. For example, in order to try a third-party library in practice, the developer is forced to pull the admin to add the corresponding repository to Nexus. For the time being, turning off this mirror in settings.xml is one more crutch.
What other options can be used to overcome the problem described? The following 3 come to mind:
- Use a mirror with the
<mirrorOf>central</mirrorOf>.
Everything works, but the benefits in performance and in saving traffic from using a mirror are few. In this case, Nexus will only proxy 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 foreign and public projects (when you cannot make changes to pom.xml). But the Nexus_a survey can be done first in the queue.
- Add Nexus as a repository to the default profile. This is an approach that combines the positive features of the above - centralized configuration and effective 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 fact, with this setting we add a default profile, which adds Nexus as a normal repository. And it is added first to the queue.
Now all requests are first sent to Nexus_y. That, depending on the presence of the requested artifact in the stored and connected proxy repositories, either gives 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 refer to the Maven central repository.
Advantages of the approach
- configured in one place, once for all projects;
- speeding up access to artifacts from all repositories registered with Nexus (including for additional repositories);
- the build does not fail if the external repository described in pom.xml is not registered with 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 approach
Only one drawback has been identified - there is a danger of forgetting to add the necessary additional repository in pom.xml. However, it should be noted that this disadvantage concerns virtually all approaches (except the 2nd) and can also manifest itself in general 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 a Nexus connected, the build will take place without problems. But developers, without a customized Nexus, will not be able to build a project at all, since Maven will not know from which additional repository 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 the pom.xml projects, in Nexus has not been canceled. This is really best done in order to get the benefit of using a proxying Maven repository. But the application of the proposed solution makes it unnecessary, which can remove the developer’s waiting time until the admin adds the required repository.
UPD: I stumbled upon an interesting article that addresses similar issues.
Source: https://habr.com/ru/post/114861/
All Articles