BACKGROUND The term & jar package:
- normal jar: Common jar, for introducing the project dependency, can not be executed java -jar xx.jar, generally does not contain other dependent jar package.
- fat jar: also known as uber jar, is an executable jar (executable jar), both contain their own code class, also includes third-party dependent jar.
- Unenforceable, but contains a third-party dependent jar package, to avoid reliance version conflicts generated jar with third parties after the introduction.
1. First class requirements: generating a single fat jar
Use maven springboot provide packaged plug-ins springboot-maven-plugin can be convenient and quick, pom configuration file is as follows:
<! - test jar package introduces local and packaging -> <! - project management perspective, try not to use local jar package, to build a unified update maven PW can manage self-study package jar -> < dependency > < groupId > cn.henry.test </ the groupId > < the artifactId > local_test </ the artifactId > < Version > 1.0.0 </ Version > < scope > System </ scope > < systemPath > $ the basedir} {/ the src / main / local_lib / local_test .jar </ systemPath > </dependency > < Build > < plugins > <-! conventional packaging, flat jar, a big play out of jar, easy to modify part of the file after an incremental release -> < plugin > < groupId > org.springframework.boot </ the groupId > < the artifactId > Spring-Boot-Maven-plugin </ the artifactId > <-! effect: simultaneous project labeled jar jar package will also be incorporated into the local -> < Configuration > < includeSystemScope > to true </ includeSystemScope > </configuration> </plugin> </plugins> </build>
2. The second type of requirement: startup items and isolated fat jar dependencies
Project files and dependent jar package separation, because there are fewer references change jar, simply replace the item or class jar package when you can release the project, the use of conventional packaging maven plugin, maven-jar-plugin, maven-dependency-plugin, output and lib for the executable jar package, pom configuration file as follows:
<! - test jar package introduces local and packaging -> <! - project management perspective, try not to use local jar package, to build a unified update maven PW can manage self-study package jar -> < dependency > < groupId > cn.henry.test </ the groupId > < the artifactId > local_test </ the artifactId > < Version > 1.0.0 </ Version > < scope > System </ scope > < systemPath > $ the basedir} {/ the src / main / local_lib / local_test .jar </ systemPath > </dependency > < Build > < plugins > <-! configuration files, and executable jar jar dependent separation bag, to facilitate replacement documents published delta -> < plugin > < the groupId > org.apache.maven.plugins </ the groupId > < the artifactId > Maven-JAR-plugin </ the artifactId > < Configuration > < Archive > < the manifest > < addClassPath > to true </ addClassPath > <!- the MANIFEST.MF Class-Path in adding the prefix-> < classpathPrefix > lib / </ classpathPrefix > <-! Specify the entry class -> < mainClass > cn.henry.study.FileMessageServer </ mainClass > </ the manifest > </ Archive > </ Configuration > </ plugin > ! <- replication dependent jar package to the specified folder, equivalent: mvn dependency: copy-Dependencies -DoutputDirectory = lib -> < plugin > < the groupId > org.apache.maven.plugins </groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>copy-dependencies</id> <phase>package</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/lib</outputDirectory> </configuration> </execution> </executions> </plugin> </plugins> </build>
3. The third category demand: available to third parties, including all common jar dependent
Building Solutions jar dependent and referenced party jar package version conflict problems and improve ease of use and independence of the jar package, the disadvantage is playing out of a larger package, built-dependent opaque jar package. Use Package maven plugin maven-shade-plugin, pom configuration file is as follows:
Switching in cmd to the directory where the local_test.jar, execute mvn install: install-file "-DgroupId = cn.henry.frame" "-DartifactId = local_test" "-Dversion = 1.0.0" "-Dpackaging = jar" "-Dfile = local_test.jar" wherein: DgroupId maven is dependent on the groupId -DartifactId maven dependence of the artifactId -Dversion is dependent maven Version DFILE local_test.jar package file name is introduced local_test.jar package after installation, maven rely as follows: <! - project management perspective, try not to use local jar package, to build a unified update maven PW can manage self-study package jar -> < dependency > < groupId > cn.henry.frame </ groupId > < artifactId > local_test </artifactId> <version> 1.0.0 </ Version > </ dependency > < Build > < plugins > <-! Available to third parties, including all common jar dependent -> < plugin > < the groupId > org.apache.maven. plugins </ the groupId > < the artifactId > Maven-plugin-Shade </ the artifactId > < Executions > < Execution > < Phase > Package </ Phase > <goals> <goal>shade</goal> </goals> <configuration> <!-- 加入启动类 --> <!--<transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>xxx.xxx</mainClass> </transformer> </transformers>--> <createDependencyReducedPom>false</createDependencyReducedPom> <filters> <filter> <artifact>*:*</artifact> <excludes> <exclude>META-INF/*.SF</exclude> <exclude>META-INF/*.DSA</exclude> <exclude>META-INF/*.RSA</exclude> </excludes> </filter> </filters> </configuration> </execution> </executions> </plugin> </plugins> </build>
4. The fourth category needs: to provide ordinary jar containing only items used by third-party code
GM mode, if there is a project to use a third-party reliance, the need to provide otherwise, will report directly to class not found exception. Use Package maven plugin maven-jar-plugin, pom configuration file is as follows:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> </manifest> </archive> </configuration> </plugin>
Note that a packaged version of the plug-selection, try to use a higher version, the official may fix the existing problems, according to the needs of the selected items are packaged.
maven plugin package official website: http://maven.apache.org/plugins
plug-packaged principle: reading xml configuration, assembled into a standard jar file
jar specifications can read the official document oracle: https://docs.oracle. com / javase / 8 / docs / technotes / guides / jar / jar.html
Part focus: MANIFEST.MF file in the JAR file format in the META-INF directory, used to define the extension and package related data. Main properties: Manifest-Version (MF file version number), Main-Class (main method comprising class), ClassPath (ClassPath performed when the jar package, dependent on a third party)
Manifest-Version: 1.0 Main-Class: test.Main Class-Path: ./ ./lib/commons-collections-3.2.jar ./lib/commons-lang-2.3.jar ./lib/commons-logging-1.1.jar
General practice is to scan the packaged items depends packet, according to values specified value of the Class-Path splicing, MF written to the file. However, this approach is not flexible enough, the frame will usually get custom information from MF files, use classloader to dynamically load dependent jar package, and merger control, filtering rules files.