The subtle differences in the order of Maven plugin declarations

This article source: http://blog.csdn.net/bluishglc/article/details/50380880 prohibited any form of reprint, or will entrust CSDN official maintenance rights!

Look at such a very interesting question:

A project needs to do the package operation like this:

• The jar package for this project was first obtained through Maven-jar-plugin, so the jar plug-in was explicitly configured to exclude unnecessary files
• Then, using Maven-shade-plugin, the project's jar package and its dependent jar are made into a all-in-one large jar package. This is not an elegant approach, but it is limited to the specific needs of certain environments, and you may have to choose
• Finally, use Maven-assembly-plugin to package the resulting All-in-one jar package and some shell files and configuration files in a common organization (such as a bin,lib,conf folder) as a bundle

Inserting a digression, someone may feel frightened when they see the three package plugins in the project, and actually from my practical experience, these three plugins have their own focus and expertise in the problem domain, there is no question of who to replace who, It is to be combined according to the needs of the project. The jar is a narrow-sense jar file Packaging tool that ultimately delivers a single jar package containing the project classes, and shade is focused on merging dependent jar packages to generate a all-in-one jar package, While Assembly has a certain ability to merge dependent jar packages, but it is not as strong as shade in this regard, its main strength is to build a distribution package with a specific directory structure and resource files.

The initial configuration is this:

<plugin>    <groupId>Org.apache.maven.plugins</groupId>    <artifactid>Maven-jar-plugin</artifactid>    <version>${jar.version}</version>    <configuration>        <excludes>            <exclude>bin/**</exclude>            <exclude>Deploy.bat</exclude>        </excludes>    </configuration></plugin><plugin>    <groupId>Org.apache.maven.plugins</groupId>    <artifactid>Maven-assembly-plugin</artifactid>    <version>${assembly.version}</version>    <inherited>False</inherited>    <executions>        <execution>            <phase>Package</phase>            <goals>                <goal>Single</goal>            </goals>        </Execution>    </executions>    <configuration>        <descriptors>            <descriptor>Src/main/assembly/bin.xml</Descriptor>        </descriptors>    </configuration></plugin><plugin>    <groupId>Org.apache.maven.plugins</groupId>    <artifactid>Maven-shade-plugin</artifactid>    <version>${shade.version}</version>    <executions>        <execution>            <phase>Package</phase>            <goals>                <goal>Shade</goal>            </goals>        </Execution>    </executions></plugin>

Under the generated target directory, you get a few important files similar to the following:

Xxx.jar (approx. 15M)
Original-xxx.jar (approx. 10K)
Xxx-bin.zip ~10k (approx. 10K)

Explain the origins of these three documents:
Original-xxx.jar was originally generated by the jar plugin only contains the project itself classes jar package, so it is very small, it was created at the beginning of the name is Xxx.jar, is the subsequent shade plug-in when working, renaming it, Shade Xxx.jar and its dependent jars are packaged together to avoid renaming the original Xxx.jar to Original-xxx.jar, and the new Xxx.jar is a collection of all dependent jars, so the volume is large. Xxx-bin.zip is a final release package that contains the Xxx.jar.

However, this configuration has a major bug:

We can see that the Xxx-bin.zip file is very small, and that the xxx.jar inside it is not a large jar of all-in-one after shade processing, but the original smaller Xxx.jar generated during the jar packaging phase. Although the above three plug-ins are bound to the package phase, but there is a "first served" order between the three , this bug implies that we, according to the above configuration, maven first execute the jar plugin, And then executed the assembly, This is why the ZIP package contains the original Xxx.jar generated by the jar plugin instead of the All-in-one large jar package generated by the Shadee plug-in, because the shade plugin was executed on the last side, so it was the last generated All-in-one large jar package and missed the Z The process of IP packaging. So Maven'sorder of execution for multiple plug-ins bound to the same phase is in the order they were declared in Pom.xml .

So the solution to modify this bug is clear, we just need to adjust the declaration order of the three plug-ins can be, the previous Maven-jar-plugin-Maven-assembly-plugin Maven-shade-plugin modified to Maven-jar-plugin, Maven-shade-plugin, Maven-assembly-plugin .

The following is the revised version:

<plugin>    <groupId>Org.apache.maven.plugins</groupId>    <artifactid>Maven-jar-plugin</artifactid>    <version>${jar.version}</version>    <configuration>        <excludes>            <exclude>bin/**</exclude>            <exclude>Deploy.bat</exclude>        </excludes>    </configuration></plugin><plugin>    <groupId>Org.apache.maven.plugins</groupId>    <artifactid>Maven-shade-plugin</artifactid>    <version>${shade.version}</version>    <executions>        <execution>            <phase>Package</phase>            <goals>                <goal>Shade</goal>            </goals>        </Execution>    </executions></plugin><plugin>    <groupId>Org.apache.maven.plugins</groupId>    <artifactid>Maven-assembly-plugin</artifactid>    <version>${assembly.version}</version>    <inherited>False</inherited>    <executions>        <execution>            <phase>Package</phase>            <goals>                <goal>Single</goal>            </goals>        </Execution>    </executions>    <configuration>        <descriptors>            <descriptor>Src/main/assembly/bin.xml</Descriptor>        </descriptors>    </configuration></plugin>

The subtle differences in the order of Maven plugin declarations