Maven packs a centralized method for executing jars __java

Source: Internet
Author: User
Tags unpack

One, no dependencies on any other jar

<build>
        <plugins>
            <plugin>
                <groupid>org.apache.maven.plugins</groupid >
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.4</version>
                < configuration>
                    <archive>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <classpathPrefix>lib/</classpathPrefix>
                            <mainclass>com.think.testmain</ mainclass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
        </plugins>
    </build>

Run: MVN clean package, find packaged in target, run after command Java-jar Xxx.jar can, but if the program has dependencies on other packages, such as a program that relies on JDBC to query db, then execution will result in no JDBC dependencies being found because we don't have the dependency pack in.


Second, when the solution depends on other packages, can execute JAR packaging

1,

<build> <plugins> <plugin> &LT;GROUPID&GT;ORG.APACHE.MAVEN.PLUGINS&L T;/groupid> <artifactId>maven-assembly-plugin</artifactId> <version>2 .3</version> <configuration> <appendassemblyid>false</appendassem Blyid> <descriptorRefs> <descriptorref>jar-with-dependencies&lt
                        ;/descriptorref> </descriptorRefs> <archive>
                        <manifest> <mainClass>com.think.TestMain</mainClass> </manifest> </archive> </configuration> <execu
                        Tions> <execution> <id>make-assembly</id> <phase>paCkage</phase> <goals> <goal>assembly</goal>
            </goals> </execution> </executions> </plugin> </plugins> </build>

But the above way is less, because we rely on the jar, will also hit into our final generated jar, this is not very good, if you generate the jar to be used by others, it is best to give a pure.

The general use of Assembly will then use his other function, our jar archive, packaged into a zip

2, into a ZIP package, the release of the project, the ZIP package copy to the server, direct unzip Xxx.zip, which contains to run to the jar and dependent Lib, as well as configuration config file, you can start the service directly

<build> <resources> <!--copy of control resource files--> <resource> <directory>src/main/resources</directory> <targetpath>${project.build.directory}/classes </targetPath> </resource> </resources> <plugins> <!--set
                source file encoding mode--> <plugin> <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> <encoding >UTF-8</encoding> </configuration> </plugin> <!--the Conf Iguration of Maven-jar-plugin--> <plugin> <groupid>org.apache.maven.plugins&lt
          ;/groupid>      <artifactId>maven-jar-plugin</artifactId> <version>2.4</version> <!--the configuration of the plugin--> <configuration> <!--Conf
                            Iguration of the archiver--> <archive> <!-- In the generated jar, do not include the two files Pom.xml and pom.properties--> <addmavendescrip
                        Tor>false</addmavendescriptor> <!--Manifest specific configuration--> <manifest> <!--Do you want to put the third party jar in manifest cl
                            Asspath--> <addClasspath>true</addClasspath> <!--the classpath prefix in the generated manifest, because the third party jar is placed in the Lib directory, so the classpath prefix is
                   lib/        --> <classpathPrefix>lib/</classpathPrefix> Main class--> < for <!--applications Mainclass>com.think.testmain</mainclass> </manifest> </archi
                    Ve> <!--filter out files that you do not want to include in the jar--> <!--<excludes>--> <!--<exclude>${project.basedir}/xml/*</exclude>--&gt
                    ;  <!--</excludes>--> </configuration> </plugin> <!--the Configuration of Maven-assembly-plugin--> <plugin> <groupid>org.apache.maven. Plugins</groupid> <artifactId>maven-assembly-plugin</artifactId> <ver SiOn>2.4</version> <!--The configuration of the plugin--> <configuration > <!--Specifies the configuration file of the assembly plugin--> <de
                    Scriptors> <descriptor>src/main/assembly/assembly.xml</descriptor> </descriptors> </configuration> <executions> ;execution> <id>make-assembly</id> <phase>package<
                        /phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plug In> </plugins> </build>



There is an important document, the name can be casually up, I used the above is Src/main/assembly/assembly.xml

<assembly> <id>bin</id> <includeBaseDirectory>false</includeBaseDirectory> <!  --eventually packaged into a zip file for release--> <formats> <format>zip</format> </formats> <!--
            Adds dependencies to zip package under Lib directory--> <dependencySets> <dependencySet> <!--do not use the artifact of the project, the third party jar do not extract, packaged into the zip file lib directory--> <useprojectartifa
            Ct>false</useprojectartifact> <!--<outputDirectory>lib</outputDirectory>-->
        <unpack>false</unpack> </dependencySet> </dependencySets> <fileSets> <!--documentation related to the project, packaged into the root directory of the zip file--> <!--<fileSet>--> <!--<directory>${p
        Roject.basedir}</directory>--> <!--<outputDirectory>/</outputDirectory>--> <!--</fileset>--> <!--to package the project configuration file into the Config directory of the zip file--> <fileSet> <directory>${deploy.dir 
                }/classes/</directory> <outputDirectory>/conf</outputDirectory> <includes>
            <include>*.xml</include> <include>*.properties</include> 
            </includes> </fileSet> <!--The project itself compiled by the jar file, packaged into the root directory of the zip file--> <fileSet> <directory>${project.build.directory}</directory> &LT;OUTPUTDIRECTORY&GT;&LT;/OUTPUTD irectory> <includes> <include>*.jar</include> &LT;/INCLUDES&G
        T
 </fileSet> </fileSets> </assembly>

Final execution command: MVN clean package, this is the way out.

Unzip the ZIP package and we see what we want, good


3, there is a packaging, above the equivalent of what we want to play into a zip package, all put together, looking neat and good-looking, but a bit cumbersome, we can actually use another plug-in to complete, do not package, that is, to see the graphic press after the file

<project xmlns= "http://maven.apache.org/POM/4.0.0" xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance" xsi:s chemalocation= "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" > < Modelversion>4.0.0</modelversion> <groupId>com.test</groupId> &LT;ARTIFACTID&GT;MYTESTJAR&L t;/artifactid> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> <name >myTestJar</name> <url>http://maven.apache.org</url> <properties> <deploy.d Ir>./target/</deploy.dir> <project.build.sourceencoding>utf-8</project.build.sourceencoding > </properties> <dependencies> <dependency> <groupid>junit</gro
            Upid> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope>;/dependency> <dependency> <groupId>com.alibaba</groupId> <artifa Ctid>druid</artifactid> <version>1.0.9</version> </dependency> ;d ependency> <groupId>mysql</groupId> <artifactid>mysql-connector-java</ar

    tifactid> <version>5.1.32</version> </dependency> </dependencies> <build> <finalName>myTest</finalName> <sourcedirectory>src/main/java</sourcedir Ectory> <resources> <!--control the copy of the resource file--> <resource> ;d irectory>src/main/resources</directory> <targetpath>${project.build.directory}</target path> </resource> </resources> <plugins> <!--set the source file encoding Method-- > <pluGin> <groupId>org.apache.maven.plugins</groupId> <artifactid>maven-co Mpiler-plugin</artifactid> <configuration> <defaultlibbundledir>lib& Lt;/defaultlibbundledir> <source>1.6</source> <target>1.6<
            /target> <encoding>UTF-8</encoding> </configuration> </plugin> <!--packaging jar files, configure manifest files, add Lib package jar dependent--> <plugin> & Lt;groupid>org.apache.maven.plugins</groupid> &LT;ARTIFACTID&GT;MAVEN-JAR-PLUGIN&LT;/ARTIFACTID&G
                T
                            <configuration> <archive> <manifest> <addClasspath>true</addClasspath> &LT;CLASSPATHPREFIX&GT;LIB/&LT;/CLASSPATHPR efix&Gt <mainClass>com.think.TestMain</mainClass> </manifest> </a
            Rchive> </configuration> </plugin> <!--copy-dependent jar bundle to lib directory--> <plugin> <groupId>org.apache.maven.plugins</groupId> <arti Factid>maven-dependency-plugin</artifactid> <executions> <execution&
                        Gt 
                            <id>copy</id> <phase>package</phase> <goals>
                        <goal>copy-dependencies</goal> </goals> <configuration> <!--${project.build.directory} is a maven variable, built into, representing the target directory, such as Do not write, will be in the directory with the creation of/lib--> <outputdirectory>${project.bUild.directory}/lib</outputdirectory> <!--excludetransitive: Do not include indirect dependencies, such as we rely on a, but a also depends on
                            B, we're going to have to hit B, too. Default not to play--> <excludeTransitive>true</excludeTransitive>
                        <!--The copied jar file removes the version information--> <stripVersion>true</stripVersion>
            </configuration> </execution> </executions> </plugin> <!--Solving the coding problem of resource files--> <plugin> &LT;GROUPID&G
                T;org.apache.maven.plugins</groupid> <artifactId>maven-resources-plugin</artifactId> <version>2.3</version> <configuration> <encoding> Utf-8</encoding> </configuration> </plugin> <!--package source file is J
            AR file--><plugin> <artifactId>maven-source-plugin</artifactId> <version>2.1
                    </version> <configuration> <attach>true</attach>
                    <encoding>UTF-8</encoding> </configuration> <executions> <execution> <phase>compile</phase>
                    ;goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> </plugins> </
 Build> </project>



Here is the Maven-dependency-plugin plug-in, the copy of the resources.

4,

<build> <resources> <resource> <targetpath>${project.build.dir Ectory}/classes</targetpath> <directory>src/main/resources</directory> & Lt;filtering>true</filtering> <includes> <include>**/*.xml</in clude> </includes> </resource> </resources> &LT;PLUGINS&G
            T <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactid>m Aven-compiler-plugin</artifactid> <version>3.0</version> <configurati
                    On> <source>1.6</source> <target>1.6</target>
            <encoding>UTF-8</encoding> </configuration> </plugin> &lT;plugin> <groupId>org.apache.maven.plugins</groupId> <artifactid>mav
                    En-shade-plugin</artifactid> <version>2.0</version> <executions> <execution> <phase>package</phase> &L
                        T;goals> <goal>shade</goal> </goals> <configuration> <transformers> <tra Nsformer implementation= "Org.apache.maven.plugins.shade.resource.ManifestResourceT
                                Ransformer "> <mainClass>com.think.TestMain</mainClass>
                                        </transformer> <!--<transformer--> <!--Implementation= "Org.apache.maven.plugins.shade.resource.AppendingTransformer" >--> <!--<resource>applicationContext.xml</resource>--> <!--</transfor Mer>--> </transformers> <shadedArtifactAttached> True</shadedartifactattached> <shadedclassifiername>executable</shadedclassifie rname> </configuration> </execution> </execu tions> </plugin> </plugins> </build>

This way of playing out is softer together and becomes a jar,

Can run directly Java-jar Xxx.jar.


We can according to different needs to package, if exposed to the outside, you can use the 4th, if it is their own company project packaging, recommendations 2, 3, because sometimes just changed a configuration file, do not need to package, directly to the configuration file copied into the

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.