About Us
At 1C we develop not only a platform on ΠΈ , but also applications in Java - in particular, a new development environment based on Eclipse and the server of a messenger deeply integrated with the platform - .
Entry
We most often use maven as a build system for Java applications, and in this short article we would like to talk about one of the problems that we had to face in the process of organizing development, and about the approach that allowed us to overcome this problem.
Prerequisites 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 in the tens or even hundreds.
It would seem: nothing terrible, once created and forgotten. If you need to change or add something in all files at once, there are a lot of handy tools in editors and IDEs. And what is the most common regular pom.xml change? We believe that the change of project versions and dependencies. Perhaps someone will want to argue with this, but this is the case with us. The reason lies in the fact that along with the kernel we develop a lot of our own libraries in parallel, and for the constant reproducibility of build and test results, using snapshots does not seem to us a convenient approach. For this reason, you have to raise the version number in projects with each build.
Also, from time to time, a developer needs to build his own branch of a library and check its performance against all dependencies, for which they all 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. This is where a handy well-known plugin comes to the rescue. versions-maven-plugin - connect it and run
mvn -N versions:set -DnewVersion=2.0.1
and maven will do everything as it should: run through the hierarchy from top to bottom, replace all versions - beauty! Now it remains to raise a pull-request, colleagues will review the changes, and you can quickly join the trunk. Quickly? No matter how. A couple of hundred pom.xml for review, and that's not counting the code. In addition, no one is immune from merge conflicts with such a large number of modified files. It should be noted here that in 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, having resigned ourselves, we lived like that until the guys from did not include in maven, starting from version 3.5.0-beta-1, support for the so-called "substitutes" versions (placeholders). The point of these substitutions is that pom.xml variables are used instead of a specific indication of the project version ${revision}, ${sha1} ΠΈ ${changelist}. The values ββof these properties themselves are set either in the elementproperties>, or they can be defined through the system property
mvn -Drevision=2.0.0 clean package
System property values ββtake precedence over values ββdefined inproperties>.
Parent
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci parent
First CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-SNAPSHOT
A descendant
4.0.0
org.apache.maven.ci
ci parent
${revision}${sha1}${changelist}
org.apache.maven.ci
ci child
...
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 reset SNAPSHOT
mvn -Dchangelist= clean package
*The examples above are taken from on the Maven Apache Project website
The harsh reality
Everything is good and great, it's time to experience a sense of satisfaction, but no. It turns out that this method will not work for install and deploy, since it will not be replaced in the descriptions of artifacts published in the repository ${revision} on its value and maven will not understand what it is all about.
org.apache
apache
${revision}
A light in the end of a tunnel
We must look for a solution to the problem. The situation could be saved . This plugin allows all variables in the pom, but at the same time cuts out a lot of other information that is only needed when building and is not needed when importing published artifacts into other projects. Also, the plugin βstraightensβ all parent-child dependencies, and as a result, flat pom are obtained, including everything that is needed. The inconvenience was that he cuts out too much "excess", which did not suit us at all. After studying the information on the development of this plugin, it turned out that we are not alone in the universe, and back in August 2018, a pull-request was created on the github in the plugin repository with the wish to make it possible to 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 the flatten-maven-plugin, which fit like never before - it leaves pom.xml as it is, except for the element and allows ${revision}, ${sha1} ΠΈ ${changelist}.
Adding a plugin to a project
org.codehaus.mojo
flatten-maven-plugin
1.1.0
true
resolveCiFriendliesOnly
flattens
process resources
flattens
flatten.clean
clean
clean
Done!
Happy ending
From now on, in order to change the version of the entire project and let all dependencies know about it, we just need to edit the elementRevision>only one root pom.xml. Not a hundred or two of these files with the same change arrive at the review, but one. Well, there is no need to use versions-maven-plugin.
Source: habr.com