foreword
At present, there is a data migration project in the project that needs to migrate the data of the old ES to MySQL, and because the version of ES is 5.X, the POM used to introduce the ES framework is very old, resulting in a large number of cases after the project is deployed. The jar package conflicts, but it can be started normally in IDEA, which makes me feel a little weird. This is also the source of inspiration for this blog, hey O(∩_∩)O
1. Install the jar package check conflict plugin
The first step is the easiest, install a plug-in to check jar package conflicts in IDEA: Maven Helper
First of all, this tool can list all conflicting jar packages, such as my project, which can be described as horrible! Note that the selected pom.xml is best to be the submodule pom.xml that is finally used for packaging, which is the most complete, and then go to the functional module to exclude these redundant jar packages, for example:
In this way, the snakeyaml and jackson-core in the antique ES package are excluded, which will cause jar conflicts.
Then I found out that this is far from enough! There are many other jar package conflicts
The error log at that time:
2. Change the project packaging method
I have used the full package method to make SpringBoot jar packages before, but these jar packages are all sealed in the entire full package and are difficult to modify, so I need to change the packaging method to expose them to the outside for easy modification
SpringBoot all-inclusive packaging method (full package)
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.3.9.RELEASE</version>
<configuration>
<finalName>${project.build.finalName}</finalName>
<mainClass>********</mainClass>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>Note: mainClass needs to fill in the SpringBoot startup class of your own project
Then change to Dependency+Assemble for packaging
<!--设置jar所依赖的三方jar包存放的路径-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dep</id>
<phase>prepare-package</phase>
<goals>
<goal>
copy-dependencies
</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>${project.build.finalName}</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>build/package.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
The build/package.xml needs to be built by yourself, and the filling method can refer to other blogs, so I won’t go into details here
Maven packaging plug-in maven-assembly-plugin configuration
maven-assembly-plugin configuration packaging - rain or shine 415 - Blog Park
The project startup script needs to be changed to java -cp, cp is the classpath, and which jar packages are loaded by the project startup by executing the classpath
For example, after packaging on my side, the startup script is placed in the bin directory, the configuration file is placed in the conf, and all the dependency jar packages are placed in the lib. Then my startup command is:
java -cp ../conf:../lib/* {包名}.ApplicationThe last {package name}.Application is the full path of your project's startup class.
3. Think about why IDEA can start normally
Finally reached the most critical step, I was wondering why IDEA can be started successfully, but it cannot be started after deployment? Why not take a look at the project startup command in IDEA?
The startup command of the IDEA project is the first line printed by the console:
Don't hesitate, copy all this line and paste it in Notepad
Wow! So much to see is dazzling, isn't it? That's right! ! This is the answer we are looking for ! ! Since the project cannot start, it must be because the version of the jar package conflicts. Isn’t it enough to just use the version number used by IDEA? It can start the project, and of course you can also start the project with the answer provided by IDEA. Combining the clues of conflicting jar packages provided by Maven Helper and the error reported when the project starts , it is easy to find jar packages with conflicting versions.
Take the error report above as an example. It reports that there is a problem with the spring-data-commons package. I checked that the packaged and deployed version of the project is 2.1.8.RELEASE, while IDEA uses 2.3.9. RELEASE, it is obvious that the package version during deployment is wrong, I immediately deleted this spring-data-commons-2.1.8.RELEASE.jar, and put spring-data-commons-2.3.9.RELEASE from the path displayed by IDEA Put the .jar on it, restart the project, and find that the error message has changed directly, and then repeat the process until the whole project starts up smoothly, so far the problem of a large number of jar package conflicts has been solved.
If the code needs to be updated later, you only need to replace the few jar packages that the project changed, and the previous jar packages do not need to be moved. Even if the project is provided externally, it is only necessary to package the current project as a whole, and there is no need to worry about the conflicts of those jar packages.