When Maven needs to download artifacts from a remote repository, it logs the progress of the download. This can lead to a lot of noise in the output. Luckily, we can suppress the logging of the download progress. Since Maven 3.6.1. we can use the command-line option --no-transfer-progress to disable the logging of the download progress. There is also a short version of the option: -ntp.
Recently I stumbled upon an example of why managing your dependencies in a maintainable way is important. The issue I had was in a multi-module project where individual Maven dependencies were overridden everywhere, the result was that a lot of dependencies were in conflict and upgrading these dependencies became quite troublesome. One of the countermeasures for me was the use of certain Maven Bill of Material (BOM).
With using a BOM I only had to set version of dependencies once and did not have to duplicate the dependency in the parent because the bom implicitly has it already.
A .mvn directory in the root of our project can contains some useful extras. For example we can set default Maven options or Java VM options when we run a Maven command. We can also define Maven extensions we want to add to the Maven classpath using the file extensions.xml in the .mvn directory. The Maven extension we want to add can be referenced using a groupId, artifactId and version inside an <extension> element. We can define one or more extensions within the parent element extensions. Once we have defined the extension and run Maven the extension is added to classpath of Maven itself.
In a previous blog we learned about setting default JVM options when we run Maven commands. We can also set default Maven options that we want to apply each time we run a Maven command. All options can be defined in the file maven.config in a .mvn directory in the root of our project. Each option must be defined on a new line. This directory and file can be added to our source control so that all users that have access to the repository will use the same Maven options.
In order to add default JVM options to our Maven mvn command we can define an environment variable MAVEN_OPTS. But we can also create a file jvm.config in the directory .mvn in our project root directory. On each line we define a Java option we want to apply. We can specify JVM options, but also Java system properties we want to apply each time we run the mvn command. This directory and file can be added to our source control so that all users that have access to the repository will use the same JVM options.
When we are working with a multi-module project in Maven we might want to exclude a module when we invoke a build command. We might only be interested in partially building some modules. We can use the command line option -pl or --projects to specify a list of modules that need to be in our build. But we can also use ! followed by the module name to exclude modules from our build.
The Maven Release plugin allows you to easily craft releases of your own libraries, to share code between projects.
When combined with Semantic Versioning you can communicate clearly to your library users which changes are minor, or potentially breaking.
The plugin will trim off the -SNAPSHOT suffix of your artifact version, run through all the stages to create your build artifacts, and push those artifacts to a remote registry such as Artifactory.
It will also push a Git tag to your code repository, as well as increment your artifact version to prepare for further development.
This blogpost will run you through the steps to authenticate with both GitLab and Artifactory when running a Maven Release from GitLab CI.
In a previous post we learned how to replace a file in an archive with Gradle.
In this blog post we use Maven to achieve the same goal.
With Maven we first have to extract the contents of the archive and then assemble a new archive where we use a file replacement to replace an original file from the archive.
To extract the contents we use the task unzip with the maven-antrun-plugin.
To create a new archive we use the maven-assembly-plugin.
The destination directory of the extracted contents is the input fileset for the assembly definition together with the files we want to overwrite.
The end result is a new archive with replaced files.
In the following pom.xml we configure the maven-antrun-plugin and maven-assembly-plugin:
Maven can be set up to use a private repository, i.e. Nexus. Usually the repository runs on http and there isn’t any problem to connect to the repository, but when the repository runs on https maven isn’t able to connect to it automatically. The solution to this is to add the server’s certificate to the default Java keystore. When connecting to your https-repository fails, Maven will show you an exception like
To resolve this, download the server’s certificate and add it to the default Java keystore.
The easiest way to download the certificate is with the Java provided keytool.
The following command is an example to download the certificate to a .pem file
As of Maven 2.0.9 a new feature was added to Maven called dependency mediation. Dependency mediation is the technique used by Maven to resolve your project dependencies in the specific case when a dependency occurs multiple times in your dependency tree. Usually this occurs on transitive dependencies linked through the dependencies of your project. In these cases mediation will be performed using the nearest win-strategy. In short this strategy means that Maven will use the version declared in the pom.xml that is closest to your project pom.xml. Hence, no in-depth intelligence is used to resolve the dependency conflict. Actually, I can't really think of a conflict resolve strategy that would really solve this problem. Any strategy I can think of has the hazard of linking incompatible dependencies in to your project. Using Maven version ranges can ofcourse resolve compatibility between artifacts, but this also requires you to establish a compatibility matrix of your dependencies. A pretty tedious task if you ask me. Now this whole mediation feature might sound like a very undesirable feature, but it's not! With this feature you can now at least be made aware of any dependency conflicts in your project dependencies. When you build your project using the -X switch, Maven will output all mediations (and a lot more) that have been performed. Now, wouldn't it be cool if there was a maven-plugin to detect mediation? JDriven took the liberty of extending Apache's dependency plugin with such a feature and share it with you. The goal used to detect mediation is mvn dependency:mediation. Additionally two interesting parameters can be added: 1) -DdisallowMediation=false 2) -DinspectArtifactId={some artifactId} As the name already implies, disallowMediation determines whether or not mediation is allowed. When allowed, the plugin will only warn about mediation being performed on dependencies. Very usefull when combined with for instance Jenkins' ${IS_M2RELEASEBUILD} variable to disallow mediation for release builds, yet allowing it for snapshot builds. The inspectArtifactId parameter is much like goal dependency:tree -Dverbose=true, it will check mediation and print dependency information regarding the artifact having id {some artifactId}. In your pom.xml your can add additional configuration to filter which dependencies must be checked on mediation:
com.jdriven.maven.plugins
maven-dependency-plugin
2.8.1
com.jdriven:\*
