I finally came across something fun at work, and was recently given a requirement to move third-party dependencies out of the POM rather than directly into a JAR package. What’s wrong with just packing

Disadvantages of direct packing

List the three deadly SINS of direct packing!!

  • If the project relies on a large number of third-party packages, the resulting jar packages will be large and time-consuming to upload
  • If you rely on a third-party package that has a security vulnerability, you have to change the version, and then you have to repackage it. Fastjson has been exposed as a security vulnerability, with a deserialization vulnerability in versions smaller than 1.2.68
  • If you rely on a third-party package version upgrade, you can use the latest version directly by modifying the version and repackaging

The second and third point is similar, it is the version that causes the repackaging, but we do not package the dependent third-party packages, so the final JAR package is not only small, but also does not need to be repackaged when the dependent third-party versions change

Since there are so many benefits to eliminating third-party packages, it’s time to take action and overhaul your project

Pom file modification

Configuring packaging-related things in maven projects is in poM files, which is usually done in POM if there is no need to exclude third-party packages

<build> <finalName>authsdk-service-${version}</finalName> <plugins> <plugin> <groupId>org.springframework.boot</groupId>  <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <finalName>authsdk-service-${version}</finalName> </configuration> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <encoding>${project.build.sourceEncoding}</encoding> <source>8</source> <target>8</target> </configuration> </plugin> </plugins> </build>Copy the code

Take a look at the size of the jar package after packaging

The size of the jar package is 27515KB. If you look at the contents of the jar package, you will find that the boot-inf /lib directory is dependent on third-party packages

Obviously, these dependent third party packages are the cause of the large packaged JAR packages. Now we need to make a change to the POM file so that it does not package the third party dependencies into the modified configuration

<build> <finalName>authsdk-service-${version}</finalName> <plugins> <plugin> <groupId>org.springframework.boot</groupId>  <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <! - here for the project of the main class path - > < mainClass > com. XXX. Authsdk. AuthsdkServiceApplication < / mainClass > < layout > ZIP < / layout > < includes > <include> <! <artifactId>nothing</artifactId> </include> </includes> </configuration> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>8</source> <target>8</target> </configuration> </plugin> </plugins> </build>Copy the code

After modification, pack the package again

The jar package size has been changed to 1702KB, which is 3/50 of the original size. / boot-INF no lib folder is available. No third party dependencies are included. Since third-party dependencies are not included in the package, we need to specify the location of third-party dependencies to start the program properly. This requires us to make sure that the lib folder is removed from the original unslimmed JAR package, which is a bit low. Maven provides a way to display the path to the specified lib folder by adding the following configuration to the previous POM file

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <! G:/ Java project /authorize_service/lib</outputDirectory> <excludeScope>provided</excludeScope> <! Skip copying third-party dependencies. This is after the first upload third-party dependencies to the server, enable this option, can not be repeated in the packaging, save time. --> <skip>false</skip> </configuration> </execution> </executions> </plugin>Copy the code

Use

to specify that the lib directory is saved in the current project path

Project start

Because third-party dependencies are not packaged, startup must show the specified third-party dependencies

  • Relative path: java-dloader. Path =\ lib-jar xxx.jar
  • Absolute path: java-dloader. Path =/ XXX/lib-jar xxx.jar