Deploying Java artifacts on a Nexus Repository with Maven
As a software project grows, the number of dependencies increases, requiring the need of managing them in a scalable manner. Different forms of management exist and they were created based on multiple projects’ natures and technologies.
For some languages, the source code needs to be compiled first in order for it to be executed by the machine. This process generates files and these files generally are related to a version. Therefore, having multiple versions without a minimum management can be quite dangerous.
This is where Maven and Nexus come into play. Together they help build and manage Java dependencies in a simple and reliable way. In this article, we will be showing how to deploy Java artifacts using both technologies, but first, let’s have a brief explanation of what they are.
Maven is a build automation tool used primarily for Java projects that addresses how software is built and its dependencies. It uses a XML file describing the software project being built, its dependencies on other external modules and components, the build order, directories, and required plug-ins. Maven dynamically downloads Java libraries and Maven plug-ins by accessing one or more repositories such as the Maven 2 Central Repository, and stores them in a local cache.
Nexus is a repository manager that stores “artifacts”, which allows you to proxy collect and manage your dependencies, making it easy to distribute your software.
When talking about “artifacts”, we mean external libraries like, for example, JARs files for Java libraries and packages for Node. This way, we can have access to multiple external libraries and different versions of them.
In this case, both Maven and Nexus were chosen because they were currently being used by our team. An alternative to Maven for artifacts deployment could be Gradle and the reason of using an internal Nexus repository is to have efficient and centralized collaboration between developers and teams in a company, besides involving issues such as company’s compliance and information security.
Getting into action!
To make this as straightforward as possible, we will be basically using the following maven commands:
- mvn deploy - Used in most project builds, it is invoked when you call the deploy phase of the default build lifecycle of a maven project.
- mvn deploy:deploy-file - Used to deploy artifacts, which are not built using Maven, to any remote repository.
To run both commands properly, we need to make some basic configurations first in order to have access to our internal Nexus repository, assuming it requires authentication (in our case it does).
Preparing the ground
First of all, we need to create a file named “settings.xml” and place it under a folder named “.m2”, which represents the local repository of Maven (in any operational system). This file will contain the “id”, “username” and “password” required to access our internal Nexus, as shown bellow:
<settings>
<servers>
<server>
<id>my-repo-id</id>
<username>my-username</username>
<password>my-password</password>
</server>
</servers>
</settings>This step is required to run both commands!
Running mvn:deploy
Add the following code snippet inside the “pom.xml” file of our maven project that we want to deploy:
<project>
...
<distributionManagement>
<repository>
<id>my-repo-id</id>
<url>https://my-nexus-repo-address.com</url>
</repository>
</distributionManagement>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>With these configurations defined, we can run our “mvn deploy” command (in this case, i ran it under IntelliJ’s maven tab):
mvn deploy -DskipTests -Dmaven.install.skip=trueIt builds our project and uploads it to the repository we defined in our “pom.xml” file. With “-DskipTests” we skip running application’s tests and “-Dmaven.install.skip=true” bypasses local artifact installation. After running it successfully, we can see the following message on IDE’s console:
We can also check the uploaded files on our Nexus:
Running mvn deploy:deploy-file
This command enables us to deploy any installed dependency on our machine to our Nexus, without the need of having its source code! The only thing we will need is the JAR file itself. This means that this can deploy any artifact, even if it was not built with Maven.
With “settings.xml” configured and placed correctly, before running the command, we need to pay attention to the name of the file we want to deploy as it must match the “-Dfile” argument value we will input. Then, we can run it from a Linux terminal:
mvn deploy:deploy-file -Durl=https://my-nexus-repo-address.com -Dfile=my-java-artifact.jar -DgroupId=com.example -DartifactId=my-java-artifact -Dpackaging=jar -Dversion=1.0.0 -DrepositoryId=my-repo-idAfter running it successfully, we should see the following message on our terminal:
We can also check the uploaded files on our Nexus:
Aaaand there you go. Our artifacts are now hosted beautifully and securely in our Nexus repository!
Conclusion
By using both Maven commands and Nexus, we have an easy and fast way of deploying java dependencies to a repository. With them, we can even “transfer”artifacts from one repository to another in case we don’t have access to their respective maven projects, which really saves a lot of possible headaches (trust me, it really is a pain).
