DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Private Remote Maven Repository With Artipie
  • How to Publish Artifacts to Maven Central
  • OpenAPI From Code With Spring and Java: A Recipe for Your CI
  • Securing CI/CD Pipelines Against Supply Chain Attacks: Why Artifacts and Dependencies Matter More Than Ever

Trending

  • S3 Vectors: How to Build a RAG Without a Vector Database
  • Build Self-Managing Data Pipelines With an LLM Agent
  • The Hidden Bottlenecks That Break Microservices in Production
  • Visualizing Matrix Multiplication as a Linear Combination
  1. DZone
  2. Coding
  3. Java
  4. Why ‘mvn install’ May Risk Your Builds

Why ‘mvn install’ May Risk Your Builds

Learn the risks of using 'mvn install' on build servers, how it affects artifacts, and solutions to avoid issues with feature branches and dependencies.

By 
Gunter Rotsaert user avatar
Gunter Rotsaert
DZone Core CORE ·
Dec. 03, 24 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
4.6K Views

Join the DZone community and get the full member experience.

Join For Free

When you are using mvn install in your build server, you should ask yourself the question of whether this is correct. You might be at risk without knowing it. In this blog, the problems with mvn install are explained, and solutions are provided. 

Introduction

You are using a build server for several reasons: builds are not dependent on a developer’s machine, you can run long integration tests or regression tests on the build server without blocking a developer’s machine, you run security checks on the build server, SonarQube analysis, and so on. 

But are your artifacts correct? You might be surprised when someone tells you that feature-branch artifacts can slip into your develop or main branch artifacts without you knowing. But this is exactly what can happen if you do not take the correct measures. In the remainder of this blog, the problems that can arise are shown, and how you can fix them.

The sources used in this blog can be found on GitHub.

Prerequisites

Prerequisites for reading this blog are:

  1. You need to be familiar with Maven (a great tutorial can be found here);
  2. Basic knowledge of Java;
  3. Basic knowledge of Git branching strategies.

Sample Applications

The source code contains three sample applications.

1. No Dependencies

Application nodep is a Java library that contains a single class NoDependencies with a method returning a string.

Java
 
public class NoDependencies {
 
    public String out() {
        return "No dependencies initial version";
    }
 
}


2. Dependencies

Application dep is a basic Java application containing a class Dependencies which uses the nodep library and prints the string to the console.

Java
 
public class Dependencies {
 
    public static void main(String[] args) {
        NoDependencies noDependencies = new NoDependencies();
        System.out.println("Dependencies has artifact: " + noDependencies.out());
    }
 
}


The library nodep is added as a dependency in the pom file.

XML
 
<dependencies>
   <dependency>
     <groupId>com.mydeveloperplanet.mymavenverifyinstallplanet</groupId>
     <artifactId>nodep</artifactId>
     <version>0.0.1-SNAPSHOT</version>
   </dependency>
 </dependencies>


3. Multimodule

Application multimodule is a Maven multimodule project that consists of two modules, multimodulenodep and multimoduledep, which are similar to the ones described above.

Verify vs. Install

First, let’s investigate the difference between mvn verify and mvn install.

1. Verify

Step into the nodep directory and build the application.

Shell
 
$ cd nodep
$ mvn clean verify
...
[INFO] --- jar:3.3.0:jar (default-jar) @ nodep ---
[INFO] Building jar: /home/<project directory>/mymavenverifyinstallplanet/nodep/target/nodep-0.0.1-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.967 s
[INFO] Finished at: 2024-11-03T15:10:12+01:00
[INFO] ------------------------------------------------------------------------


The build is successful, and the output shows that the artifact nodep-0.0.1-SNAPSHOT.jar was put in the target directory.

Exit the nodep directory, step into the dep directory, and build the application.

Shell
 
$ cd ..
$ cd dep
$ mvn clean verify
...
[INFO] Building Dependencies 0.0.1-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[WARNING] The POM for com.mydeveloperplanet.mymavenverifyinstallplanet:nodep:jar:0.0.1-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.196 s
[INFO] Finished at: 2024-11-03T15:13:06+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project dep: Could not resolve dependencies for project com.mydeveloperplanet.mymavenverifyinstallplanet:dep:jar:0.0.1-SNAPSHOT: The following artifacts could not be resolved: com.mydeveloperplanet.mymavenverifyinstallplanet:nodep:jar:0.0.1-SNAPSHOT (absent): Could not find artifact com.mydeveloperplanet.mymavenverifyinstallplanet:nodep:jar:0.0.1-SNAPSHOT -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException


The build fails because the artifact nodep-0.0.1-SNAPSHOT.jar cannot be found in the local Maven repository (~/.m2/repository) and it is also not available in a remote Maven repository.

Exit the dep directory, step into the multimodule directory, and build the application.

Shell
 
$ cd ..
$ cd multimodule/
$ mvn clean verify
...
[INFO] --- jar:3.3.0:jar (default-jar) @ multimoduledep ---
[INFO] Building jar: /home/<project directory>/mymavenverifyinstallplanet/multimodule/multimoduledep/target/multimoduledep-0.0.1-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Multimodule project 0.0.1-SNAPSHOT:
[INFO] 
[INFO] Multimodule project ................................ SUCCESS [  0.085 s]
[INFO] No dependencies .................................... SUCCESS [  0.627 s]
[INFO] Dependencies ....................................... SUCCESS [  0.111 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.874 s
[INFO] Finished at: 2024-11-03T15:17:07+01:00
[INFO] ------------------------------------------------------------------------


This builds successfully because the Maven Reactor, which is responsible for the build, knows where the artifacts are located, and thus, dependencies between modules are successfully resolved.

2. Install

The solution for solving the problem with the dep application is to use mvn install. This will install the artifacts in the local Maven repository, and then they can be resolved.

Step into the nodep directory and build the application.

Shell
 
$ cd nodep
$ mvn clean install
...
[INFO] --- install:3.1.1:install (default-install) @ nodep ---
[INFO] Installing /home/<project directory/mymavenverifyinstallplanet/nodep/pom.xml to /home/<user>/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/nodep/0.0.1-SNAPSHOT/nodep-0.0.1-SNAPSHOT.pom
[INFO] Installing /home/<project directory/mymavenverifyinstallplanet/nodep/target/nodep-0.0.1-SNAPSHOT.jar to /home/<user>/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/nodep/0.0.1-SNAPSHOT/nodep-0.0.1-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.868 s
[INFO] Finished at: 2024-11-03T15:21:46+01:00
[INFO] ------------------------------------------------------------------------


Again, this builds successfully. The only difference is that the artifacts are now also installed in the local Maven repository.

Exit the nodep directory, step into the dep directory, and build the application.

Shell
 
$ cd ..
$ cd dep
$ mvn clean install
...
[INFO] --- install:3.1.1:install (default-install) @ dep ---
[INFO] Installing /home/<project directory>/mymavenverifyinstallplanet/dep/pom.xml to /home/<user>/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/dep/0.0.1-SNAPSHOT/dep-0.0.1-SNAPSHOT.pom
[INFO] Installing /home/<project directory>/mymavenverifyinstallplanet/dep/target/dep-0.0.1-SNAPSHOT.jar to /home/<user>/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/dep/0.0.1-SNAPSHOT/dep-0.0.1-SNAPSHOT.jar
[INFO] Installing /home/<project directory>/mymavenverifyinstallplanet/dep/target/dep-0.0.1-SNAPSHOT-jar-with-dependencies.jar to /home/<user>/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/dep/0.0.1-SNAPSHOT/dep-0.0.1-SNAPSHOT-jar-with-dependencies.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.110 s
[INFO] Finished at: 2024-11-03T15:24:16+01:00
[INFO] ------------------------------------------------------------------------


This time, the application builds successfully as the nodep-0.0.1-SNAPSHOT.jar dependency can be found in the local Maven repository.

Exit the dep directory, step into the multimodule directory, and build the application.

Shell
 
$ cd ..
$ cd multimodule/
$ mvn clean install
...
[INFO] --- install:3.1.1:install (default-install) @ multimoduledep ---
[INFO] Installing /home/<project directory>/mymavenverifyinstallplanet/multimodule/multimoduledep/pom.xml to /home/<user>/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/multimoduledep/0.0.1-SNAPSHOT/multimoduledep-0.0.1-SNAPSHOT.pom
[INFO] Installing /home/<project directory>/mymavenverifyinstallplanet/multimodule/multimoduledep/target/multimoduledep-0.0.1-SNAPSHOT.jar to /home/<user>/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/multimoduledep/0.0.1-SNAPSHOT/multimoduledep-0.0.1-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Multimodule project 0.0.1-SNAPSHOT:
[INFO] 
[INFO] Multimodule project ................................ SUCCESS [  0.125 s]
[INFO] No dependencies .................................... SUCCESS [  0.561 s]
[INFO] Dependencies ....................................... SUCCESS [  0.086 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.825 s
[INFO] Finished at: 2024-11-03T15:26:57+01:00
[INFO] ------------------------------------------------------------------------


Also, this build is still successful, and the artifacts can be found in the local Maven repository.

Feature Branches

So, problem solved, right? Not exactly. If you build develop branches and feature branches on your build server, you might get some unpleasant surprises.

First, let’s run the dep application with the artifact in the local Maven repository.

Shell
 
$ java -jar ~/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/dep/0.0.1-SNAPSHOT/dep-0.0.1-SNAPSHOT-jar-with-dependencies.jar 
Dependencies has artifact: No dependencies initial version


As expected, the initial version text is printed.

Let’s create a feature branch for the nodep application and change the text. You can just switch to branch feature-newversion. The NoDependencies class is the following.

Java
 
public class NoDependencies {
 
    public String out() {
        return "No dependencies new version";
    }
 
}


In real life, you commit and push the changes to your remote git repository, and the build server starts building the feature branch using mvn install. So, in order to simulate this behavior, build the nodep application locally.

Shell
 
$ cd nodep
$ mvn clean install


Switch back to the master branch and build the dep application.

Shell
 
$ cd dep
$ mvn clean install


Run the application.

Shell
 
$ java -jar ~/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/dep/0.0.1-SNAPSHOT/dep-0.0.1-SNAPSHOT-jar-with-dependencies.jar 
Dependencies has artifact: No dependencies new version


Voila! The dep artifact now contains the jar file build by the feature branch, not the one in the master branch. This means that without you knowing, unfinished work slides into a more stable branch.

Conclusion: you cannot use mvn install for feature branches, only for the develop or master/main branch.

Build Stages

Problem solved? Not exactly. It is quite common that your build pipeline consists of several stages. Each stage can be a separate invocation of a Maven command. Can the build pipeline be successfully executed when mvn verify is used?

First, clear the local Maven repository.

Shell
 
$ rm -r ~/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/


Step into the nodep directory, build the application and execute the Exec Maven Plugin which will just echo Hello there to the console.

Shell
 
$ cd nodep
$ mvn clean verify
$ mvn exec:exec
[INFO] Scanning for projects...
[INFO] 
[INFO] -------< com.mydeveloperplanet.mymavenverifyinstallplanet:nodep >-------
[INFO] Building No dependencies 0.0.1-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- exec:3.5.0:exec (default-cli) @ nodep ---
Hello there
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.183 s
[INFO] Finished at: 2024-11-03T15:47:00+01:00
[INFO] ------------------------------------------------------------------------


This works. Before continuing with the dep application, you must ensure that the nodep jar can be resolved. Therefore, execute an install. This will simulate that the nodep artifact can be retrieved from a remote Maven repository.

Shell
 
$ mvn clean install


Exit the nodep directory, step into the dep directory, build the application, and execute the Exec Maven Plugin.

Shell
 
$ cd ..
$ cd dep
$ mvn clean verify
$ mvn exec:exec
[INFO] Scanning for projects...
[INFO] 
[INFO] --------< com.mydeveloperplanet.mymavenverifyinstallplanet:dep >--------
[INFO] Building Dependencies 0.0.1-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- exec:3.5.0:exec (default-cli) @ dep ---
Hello there
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.178 s
[INFO] Finished at: 2024-11-03T15:50:34+01:00
[INFO] ------------------------------------------------------------------------


Also successful.

Exit the dep directory, step into the multimodule directory, build the application, and execute the Exec Maven Plugin.

Shell
 
$ cd ..
$ cd multimodule/
$ mvn clean verify
$ mvn exec:exec
...
[INFO] --< com.mydeveloperplanet.mymavenverifyinstallplanet:multimoduledep >---
[INFO] Building Dependencies 0.0.1-SNAPSHOT                               [3/3]
[INFO]   from multimoduledep/pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Multimodule project 0.0.1-SNAPSHOT:
[INFO] 
[INFO] Multimodule project ................................ SUCCESS [  0.080 s]
[INFO] No dependencies .................................... SUCCESS [  0.015 s]
[INFO] Dependencies ....................................... FAILURE [  0.005 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.175 s
[INFO] Finished at: 2024-11-03T15:51:57+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project multimoduledep: Could not resolve dependencies for project com.mydeveloperplanet.mymavenverifyinstallplanet:multimoduledep:jar:0.0.1-SNAPSHOT: The following artifacts could not be resolved: com.mydeveloperplanet.mymavenverifyinstallplanet:multimodulenodep:jar:0.0.1-SNAPSHOT (absent): Could not find artifact com.mydeveloperplanet.mymavenverifyinstallplanet:multimodulenodep:jar:0.0.1-SNAPSHOT -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <args> -rf :multimoduledep


This fails. Because the multimoduledep module depends on the multimodulenodep module, the Maven Reactor cannot find the necessary artifacts because the Maven commands are executed in two separate runs. If you execute the commands simultaneously, the build will be successful.

Shell
 
$ mvn clean verify exec:exec


This is how this problem can be solved, but then you cannot have multiple build stages anymore.

Final Solution

This last problem can be fixed by adding some extra arguments when executing the Maven commands. These arguments will be used in combination with mvn install and will install artifacts in a separate part of the local Maven repository. Add the arguments:

  • -Daether.enhancedLocalRepository.split
  • -Daether.enhancedLocalRepository.localPrefix=branches/feature-newversion

The first will allow you to have a split local repository. The second will create a split local repository within the ~/.m2/repository directory to store the artifacts of your build. You can choose the local prefix yourself.

1. Feature Branches

Check out the feature branch feature-newversion and execute the following commands for each application.

Shell
 
$ mvn clean install -Daether.enhancedLocalRepository.split  -Daether.enhancedLocalRepository.localPrefix=branches/feature-newversion
$ mvn exec:exec -Daether.enhancedLocalRepository.split  -Daether.enhancedLocalRepository.localPrefix=branches/feature-newversion


Every build is successful, and the Exec Maven Plugin can also be executed successfully. All artifacts are now located in ~/.m2/repository/branches/feature-newversion.

Run the dep application, the new version of nodep is used.

Shell
 
$ java -jar ~/.m2/repository/branches/feature-newversion/com/mydeveloperplanet/mymavenverifyinstallplanet/dep/0.0.1-SNAPSHOT/dep-0.0.1-SNAPSHOT-jar-with-dependencies.jar 
Dependencies has artifact: No dependencies new version


2. Master Branch

Switch to the master branch and execute the following commands for each application.

Shell
 
$ mvn clean install
$ mvn exec:exec


Every build is successful, and the Exec Maven Plugin can also be executed successfully. All artifacts are located in ~/.m2/repository/.

Run the dep application, the initial version of nodep is used.

Shell
 
$ java -jar ~/.m2/repository/com/mydeveloperplanet/mymavenverifyinstallplanet/dep/0.0.1-SNAPSHOT/dep-0.0.1-SNAPSHOT-jar-with-dependencies.jar 
Dependencies has artifact: No dependencies initial version


Conclusion

Depending on the setup of your build server, you can choose one of the solutions above. So, should you use mvn verify or mvn install? Well, it depends. The solution providing the most flexibility is the one shown in the final solution.

Apache Maven Artifact (UML) Build engine

Published at DZone with permission of Gunter Rotsaert. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Private Remote Maven Repository With Artipie
  • How to Publish Artifacts to Maven Central
  • OpenAPI From Code With Spring and Java: A Recipe for Your CI
  • Securing CI/CD Pipelines Against Supply Chain Attacks: Why Artifacts and Dependencies Matter More Than Ever

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook