April 26, 2019 at 11:02Experience using flatten-maven-plugin to simplify versioning in maven projects
About us
In 1C, we develop not only the 1C: Enterprise platform in C ++ and JavaScript , but also Java applications - in particular, the new Enterprise Development Tools development environment based on Eclipse and a server deeply integrated with the messenger platform - Interaction Systems .
Introduction
Most often we use maven as the system for assembling Java applications, and in this short article we would like to talk about one of the problems that we had to deal with during the development process and the approach that allowed us to overcome this problem.
Background and Workflow
Due to the specifics of development in our maven-projects, we use a lot of modules, dependencies and child projects. The number of pom-files in one tree can be tens or even hundreds.
It would seem: it's okay, once created and forgotten. If you need to change or add something in all files at once, there are many convenient tools in editors and IDEs. And what is the most common regular change to pom.xml? We believe that changing project versions and dependencies. Maybe someone wants to argue with this, but this is the case with us. The reason is that, along with the kernel, we are simultaneously developing many of our own libraries, and for the constant reproducibility of the assembly and testing results, the use of snapshots does not seem to us a convenient approach. For this reason, it is necessary to raise the version number in the projects at each assembly.
Also, the developer from time to time there is a need to collect his branch of a library and check its performance against all dependencies, for which all of them have to manually change the version.
Initial decision
With such frequent and multiple version changes, the process within CI wants to be simplified and automated. Here the convenient well-known plugin versions-maven-plugin comes to the rescue - plug it in and run
mvn -N versions: set -DnewVersion = 2.0.1
and the maven will do everything as it should: run through the hierarchy from top to bottom, all versions will be replaced - beauty! Now it remains to raise the pull-request, colleagues will watch the changes, and you can quickly join the trunk. Quickly? No matter how. A couple of hundreds pom.xmlon a review, and that's not counting the code. In addition, no one is safe from merge conflicts with such a large number of modified files. It should be noted here that during the CI process, version changes occur automatically along with a change in functionality, and not somehow separately.
New opportunities
For a while, we calmed down and lived in peace, until the guys from the Maven Apache Project included in maven, starting with version 3.5.0-beta-1, support for the so-called "placeholders" of versions (placeholders). The essence of these substitutes is that pom.xml uses the variables $ {revision} , $ {sha1} and $ {changelist} instead of specifying the project version . The values of these properties themselves are set either in the < properties > element , or they can be defined through the system property
mvn -Drevision = 2.0.0 clean package
The values of system properties take precedence over the values defined in < properties >.
Parent
...
Descendant
...
If you want to build version 2.0.0-SNAPSHOT, then just use
mvn -Drevision = 2.0.0 clean package
If you want to make a release, then just zero out SNAPSHOT
mvn -Dchangelist = clean package
* The examples above are taken from the article on the Maven Apache Project website
Harsh reality
Everything is good and healthy, it's time to experience a feeling of satisfaction, but no. It turns out that for install and deploy this method will not work, because $ {revision} will not be replaced with its value in the descriptions of artifacts published in the repository and maven will not understand what it is all about.
A light in the end of a tunnel
We must look for a solution to the problem. Flatten-maven-plugin could save the situation. This plugin allows all variables in pom, but at the same time it cuts out a ton of other information that is needed only during assembly and is not needed when importing published artifacts to other projects. Also, the plugin “straightens out” all parent-child dependencies, and as a result we get flat pom, which includes everything you need. The inconvenience was that he cuts out "too much" too much, which did not suit us at all. After studying the information on developing this plugin, it turned out that we are not the only ones in the universe, and back in August 2018 a pull-request was created on the github in the plugin repository with the desire to make it possible to independently determine how to “spoil” pom.xml. The developers listened to the voices of the afflicted, and already in December, with the release of the new version 1.1.0, a new resolveCiFriendliesOnly mode appeared in flatten-maven-plugin,
Add a plugin to the project
Done!
Happy end
From now on, in order to change the version of the entire project and let all the dependencies know about it, we just need to edit the < revision > element in only one root pom.xml . It’s not a hundred or two of these files with the same change that flies into the review, but one. Well, there is no need to use versions-maven-plugin .