3
头图

Hello everyone, I'm Bo Saidong, an open source author who has randomly entered the public account blogger. Today, I share a little maven trick, hoping to help everyone.

A group friend asked me in a private chat before, how to quickly and uniformly change all the maven version numbers in the project. He said that they were manually modified one by one before. There are more than 30 maven modules in the project. Last time, I changed one because I missed it. , and also caused production accidents.

In fact, some of my own open source projects have a lot of projects, and some projects together with test case modules can reach as many as 30 or 40. In the past, I used global search and replace to operate, but later I found that sometimes brainless global replacement is also easy to replace by mistake. For example, the version of the project is 1.2.0, I thought of replacing it with 1.2.1, but global brainless replacement At times, the version numbers of some other packages that were originally 1.2.0 will be replaced with 1.2.1. So even if it is a global replacement, it is necessary to check again one by one.

Is there a way that is convenient and less error-prone?

Today I recommend 2 tips, especially the second one. Most people don't know it. After using it, I feel that even if there are 100 modules, there is no need to panic.

one

Use versions-maven-plugin this plugin to do it.

First define the following maven plugin in your main pom file:

 <build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.3</version>
        </plugin>
    </plugins>
</build>

Then if you want to change the version numbers of all modules, a single command can be done:

 mvn versions:set -DnewVersion=1.2.1

If you regret updating, you can roll back:

 mvn versions:revert

If you're sure, enter the commit command and you're done:

 mvn versions:commit

Modified in this way, no matter how many submodules you have, you can modify them uniformly. The modified pom, parent references, including reference version numbers between submodules, will be changed together.

Is it very convenient.

two

In fact, many of my previous projects used the above plugin to update the submodule version number.

But some time ago, a contributor gave a PR to my open source project and used another way to modify the version number. I looked at this way later, and it was more convenient. You don't even have to type a command!

The core idea of this approach is to use placeholders for unified management.

The main pom is defined like this:

Submodules referencing other submodule versions are similarly defined:

This ${reversion} parameter is defined in the main pom:

 <properties>
        <revision>2.8.5</revision>
</properties>

If you just define it like this, the compilation will not pass, and you need to add a plugin. The role of this plugin is to automatically replace the ${reversion} placeholder when compiling and packaging:

 <plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>flatten-maven-plugin</artifactId>
  <version>1.2.7</version>
  <configuration>
    <updatePomFile>true</updatePomFile>
    <flattenMode>resolveCiFriendliesOnly</flattenMode>
  </configuration>
  <executions>
    <execution>
      <id>flatten</id>
      <phase>process-resources</phase>
      <goals>
        <goal>flatten</goal>
      </goals>
    </execution>
    <execution>
      <id>flatten.clean</id>
      <phase>clean</phase>
      <goals>
        <goal>clean</goal>
      </goals>
    </execution>
  </executions>
</plugin>

After completing the above steps, when you want to modify the version number, you only need to modify the reversion once in the main pom, no matter how many submodules, it can take effect.

At present, my open source project adopts this mode to modify the version number. Basically you don't have to worry about making mistakes.

three

In fact, in the process of daily development, we always hope to get rid of some mechanized and meaningless repetitive operations to make ourselves more efficient. If you feel that too much energy is wasted in a certain area, there must be a more efficient and simple way to solve it. I will also share some tips to improve work efficiency in the future. If you like this type of work, please like and share.

I am Bo Saidong, an open source author and a technical content blogger. I hope you will follow me, and you can also go to my open source homepage to learn about my two open source projects:

LiteFlow:

https://gitee.com/dromara/liteFlow

TLog:

https://gitee.com/dromara/TLog

If you think it is helpful to you, please don't forget to click on your honorable star😊.


铂赛东
1.2k 声望10.4k 粉丝

开源作者&内容创作者,专注于架构,开源,微服务,分布式等领域的技术研究和原创分享