Exec Maven plugin comprehensive parsing and use example

The original Article connection: http://blog.csdn.net/bluishglc/article/details/7622286, reproduced please indicate the source!

1. Why is exec used?

Current projects often rely on a large number of jar packages. Unlike war package projects, for local Java applications packaged as jar packages, starting with a Java command will be a very tedious task. The reason is very simple. Too many dependencies make the parameter-classpath abnormal. Therefore, when releasing an application, two methods are generally used to start the application: one is to package the project and all its dependent jar packages into an independent jar package (in Maven, there are two plug-ins assemly and shade for this purpose ); another method is to compile a run. the bat file contains a Java command to start the application. Obviously, the classpath of this command must contain all dependent jar packages. However, for applications that are still in the development stage, the first method needs to decompress all the jar packages and re-package them. This is very time-consuming, especially when the project is very large. The problem with the second method is that for projects in the development stage, you often need to introduce or upgrade the jar package, which requires frequent modification of the run. BAT file. In fact, for projects managed by Maven, you can use Maven to obtain the classpath of the project and simplify the startup command of the application. This is the primary motivation for the maven plug-in Exec to be designed. The biggest advantage of using exec over using Java commands to start an application is that you don't need to worry about-classpath any more.

2. What is the difference between Exec: exec and Exec: Java?

Exec is mainly composed of two goal: Exec: exec and Exec: Java. How should you choose? First, remember that exec: exec is always more powerful and flexible than Exec: Java, which will be shown in the following examples, the main difference between the two is that in thread management: Exec: exec always starts a new thread and exits from the VM (closes the application) when only the daemon thread is left ). For Exec: Java, when all non-daemon threads end, the daemon thread will be joine or interrupt, and the program will not close. However, for general users, this difference is not important. Generally, if your project is very easy to start and you do not need to set JVM parameters, system attributes, and command line parameters, Exec: Java is used, you only need to specify mainclass, and everything will be OK. For example:

<plugin><groupId>org.codehaus.mojo</groupId><artifactId>exec-maven-plugin</artifactId><version>1.2.1</version><executions><execution><goals><goal>java</goal></goals></execution></executions><configuration><mainClass>com.yourcompany.app.Main</mainClass></configuration></plugin>

If, on the contrary, your application is very complex to start, and you need to set JVM parameters, system properties, command line parameters, and so on, then you need to use Exec: exec, let's take a look at the Exec: EXEC "good" "big" "full" example.

3. An example of "good", "big", and "full"

Assume that our application is started using the following Java command:

Java-dsystemproperty1 = value1-dsystemproperty2 = value2-XX: maxpermsize = 256 m-classpath... com. yourcompany. App. Main arg1 arg2

This startup command sets the necessary system properties systemproperty1 and systemproperty2 for the application, and then sets a JVM parameter, followed by the program classpath ,.... the omitted part is the lengthy class path that you can think of without saying it. The next step is the program entry-the Class Name of the main class. arg1 arg2 is the command line parameter passed to the application.

3.1. Configure in XML:

First, let's take a look at how to implement this startup command through configuration in POM:

<Plugin> <groupid> Org. codehaus. mojo </groupid> <artifactid> Exec-Maven-plugin </artifactid> <version> 1.2.1 </version> <configuration> <executable> JAVA </executable> <! -- Executable refers to the command to be executed --> <arguments> <argument>-dsystemproperty1 = value1 </argument> <! -- This is a system property parameter --> <argument>-dsystemproperty2 = value2 </argument> <! -- This is a system property parameter --> <argument>-XX: maxpermsize = 256 m </argument> <! -- This is a JVM parameter --> <! -- Automatically creates the classpath using all project dependencies, also adding the Project Build directory --> <argument>-classpath </argument> <! -- This is the classpath attribute, and its value is <classpath/> --> <classpath/> <! -- This is the most valuable part of the exec plug-in. The classpath of the project does not need to be manually specified. It will be calculated automatically by exec --> <argument> COM. yourcompany. app. main </argument> <! -- Program entry, main class name --> <argument> arg1 </argument> <! -- The First Command Line Parameter of the program --> <argument> arg2 </argument> <! -- The second command line parameter of the program --> </arguments> </configuration> </plugin>

Add the above configuration to POM and save it. Then execute:

MVN Exec: Exec

You can start the application.

3.2. Configure in the command line:

In addition to being written in the POM configuration file, exec also supports more flexible command line startup. You can declare that only the exec plug-in has been introduced in your pom and do not provide any configuration content, then, SET related parameters in the command line. For example, if you use the command line to configure parameters, the command will be:

MVN Exec: exec -dexec.exe cutable = "Java"-dexec. ARGs = "-dsystemproperty1 = value1-dsystemproperty2 = value2-XX: maxpermsize = 256 m-classpath % classpath COM. yourcompany. app. main arg1 arg2"

How about it? Does it look more concise?

Note: exec. ARGs refers to the commandlineargs parameter of Exec: exec, and the parameter in the preceding xml configuration is arguments. The two parameters are different. This method is better, because exec stipulates that if commandlineargs exists, commandlineargs will be used first. If no argument is configured, we will be given the opportunity to execute different parameters in the command line. The following is a description on the exec Website:

1. If commandlineargs is specified, it will be used as is, doesn t for replacing % classpath with proper classpath using Dependencies
2. Otherwise if the property exec. ARGs is specified, it will be used
3. Otherwise the list of argument and classpath will be parsed and used