maven plugin介绍

http://maven.apache.org/guides/mini/guide-configuring-plugins.html

Guide to Configuring Plug-ins

1. Generic Configuration
   1. Help Goal
   2. Configuring Parameters
      1. Mapping Simple Objects
      2. Mapping Complex Objects
      3. Mapping Collections
         1. Mapping Lists
         2. Mapping Maps
         3. Mapping Properties
2. Configuring Build Plugins
   1. Using the <executions> Tag
   2. Using the <dependencies> Tag
   3. Using the <inherited> Tag In Build Plugins
3. Configuring Reporting Plugins
   1. Using the <reporting> Tag VS <build> Tag
   2. Using the <reportSets> Tag
   3. Using the <inherited> Tag In Reporting Plugins

Introduction

In Maven, there are the build and the reporting plugins:

• Build plugins will be executed during the build and then, they should be configured in the <build/> element.
• Reporting plugins will be executed during the site generation and they should be configured in the <reporting/> element.

All plugins should have minimal required informations: groupId, artifactId and version.

Important Note: It is recommended to always defined each version of the plugins used by the build to guarantee the build reproducibility. A good practice is to specify them in the <build><pluginManagement/></build> elements foreach build plugins (generally, you will define a <pluginManagement/> element in a parent POM). For reporting plugins, you should specify each version in the <reporting><plugins/></reporting> elements (and surely in the <build><pluginManagement/></build> elements too).

Generic Configuration

Maven plugins (build and reporting) are configured by specifying a <configuration> element where the child elements of the <configuration> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal). Say, for example, we had a Mojo that performed a query against a particular URL, with a specified timeout and list of options. The Mojo might look like the following:

1. /**
2. * @goal query
3. */
4. public class MyQueryMojo
5. extends AbstractMojo
6. {
7. /**
8. * @parameter expression="${query.url}"
9. */
10. private String url;
11. /**
12. * @parameter default-value="60"
13. */
14. private int timeout;
15. /**
16. * @parameter
17. */
18. private String[] options;
19. public void execute()
20. throws MojoExecutionException
21. {
22. ...
23. }
24. }

To configure the Mojo from your POM with the desired URL, timeout and options you might have something like the following:

1. <project>
2. ...
3. <build>
4. <plugins>
5. <plugin>
6. <artifactId>maven-myquery-plugin</artifactId>
7. <version>1.0</version>
8. <configuration>
9. <url>http://www.foobar.com/query</url>
10. <timeout>10</timeout>
11. <options>
12. <option>one</option>
13. <option>two</option>
14. <option>three</option>
15. </options>
16. </configuration>
17. </plugin>
18. </plugins>
19. </build>
20. ...
21. </project>

As you can see the elements in the configuration match the names of the fields in the Mojo. The configuration mechanism Maven employs is very similar to the way XStream works where elements in XML are mapped to objects. So from the example above you can see that the mapping is pretty straight forward the url element maps to the url field, the timeout element maps to the timeout field and the options element maps to the options field. The mapping mechanism can deal with arrays by inspecting the type of the field and determining if a suitable mapping is possible.

For mojos that are intended to be executed directly from the CLI, their parameters usually provide a means to be configured via system properties instead of a <configuration> section in the POM. The plugin documentation for those parameters will list an expression that denotes the system properties for the configuration. In the mojo above, the parameter url is associated with the expression ${query.url}, meaning its value can be specified by the system propertyquery.url as shown below:

1. mvn myquery:query -Dquery.url=http://maven.apache.org

Note that the name of the system property does not necessarily match the name of the mojo parameter. While this is a rather common practice, you will often notice plugins that employ some prefix for the system properties to avoid name clashes with other system properties. Though rarely, there are also plugin parameters that (e.g. for historical reasons) employ system properties which are completely unrelated to the parameter name. So be sure to have a close look at the plugin documentation.

Help Goal

Recent Maven plugins have generally an help goal to have in the command line the description of the plugin, with their parameters and types. For instance, to understand the javadoc goal, you need to call:

1. mvn javadoc:help -Ddetail -Dgoal=javadoc

And you will see all parameters for the javadoc:javadoc goal, similar to this page.

Configuring Parameters

Mapping Simple Objects

Mapping simple types, like Boolean or Integer, is very simple. The <configuration> element might look like the following:

1. ...
2. <configuration>
3. <myString>a string</myString>
4. <myBoolean>true</myBoolean>
5. <myInteger>10</myInteger>
6. <myDouble>1.0</myDouble>
7. <myFile>c:\temp</myFile>
8. <myURL>http://maven.apache.org</myURL>
9. </configuration>
10. ...

Mapping Complex Objects

Mapping complex types is also fairly straight forward in Maven so let‘s look at a simple example where we are trying to map a configuration for Person object. The <configuration/> element might look like the following:

1. ...
2. <configuration>
3. <person>
4. <firstName>Jason</firstName>
5. <lastName>van Zyl</lastName>
6. </person>
7. </configuration>
8. ...

The rules for mapping complex objects are as follows:

• There must be a private field that corresponds to name of the element being mapped. So in our case the person element must map to a person field in the mojo.
• The object instantiated must be in the same package as the Mojo itself. So if your mojo is in com.mycompany.mojo.query then the mapping mechanism will look in that package for an object named Person. As you can see the mechanism will capitalize the first letter of the element name and use that to search for the object to instantiate.
• If you wish to have the object to be instantiated live in a different package or have a more complicated name then you must specify this using an implementation attribute like the following:

1. ...
2. <configuration>
3. <person implementation="com.mycompany.mojo.query.SuperPerson">
4. <firstName>Jason</firstName>
5. <lastName>van Zyl</lastName>
6. </person>
7. </configuration>
8. ...

Mapping Collections

The configuration mapping mechanism can easily deal with most collections so let‘s go through a few examples to show you how it‘s done:

Mapping Lists

Mapping lists works in much the same way as mapping to arrays where you a list of elements will be mapped to the List. So if you have a mojo like the following:

1. public class MyAnimalMojo
2. extends AbstractMojo
3. {
4. /**
5. * @parameter
6. */
7. private List animals;
8. public void execute()
9. throws MojoExecutionException
10. {
11. ...
12. }
13. }

Where you have a field named animals then your configuration for the plug-in would look like the following:

1. <project>
2. ...
3. <build>
4. <plugins>
5. <plugin>
6. <artifactId>maven-myanimal-plugin</artifactId>
7. <version>1.0</version>
8. <configuration>
9. <animals>
10. <animal>cat</animal>
11. <animal>dog</animal>
12. <animal>aardvark</animal>
13. </animals>
14. </configuration>
15. </plugin>
16. </plugins>
17. </build>
18. ...
19. </project>

Where each of the animals listed would be entries in the animals field. Unlike arrays, collections have no specific component type. In order to derive the type of a list item, the following strategy is used:

1. If the XML element contains an implementation hint attribute, that is used
2. If the XML tag contains a ., try that as a fully qualified class name
3. Try the XML tag (with capitalized first letter) as a class in the same package as the mojo/object being configured
4. If the element has no children, assume its type is String. Otherwise, the configuration will fail.

Mapping Maps

In the same way, you could define maps like the following:

1. ...
2. /**
3. * My Map.
4. *
5. * @parameter
6. */
7. private Map myMap;
8. ...

1. ...
2. <configuration>
3. <myMap>
4. <key1>value1</key1>
5. <key2>value2</key2>
6. </myMap>
7. </configuration>
8. ...

Mapping Properties

Properties should be defined like the following:

1. ...
2. /**
3. * My Properties.
4. *
5. * @parameter
6. */
7. private Properties myProperties;
8. ...

1. ...
2. <configuration>
3. <myProperties>
4. <property>
5. <name>propertyName1</name>
6. <value>propertyValue1</value>
7. <property>
8. <property>
9. <name>propertyName2</name>
10. <value>propertyValue2</value>
11. <property>
12. </myProperties>
13. </configuration>
14. ...

Configuring Build Plugins

The following is only to configure Build plugins in the <build> element.

Using the <executions> Tag

You can also configure a mojo using the <executions> tag. This is most commonly used for mojos that are intended to participate in some phases of the build lifecycle. Using MyQueryMojo as an example, you may have something that will look like:

1. <project>
2. ...
3. <build>
4. <plugins>
5. <plugin>
6. <artifactId>maven-myquery-plugin</artifactId>
7. <version>1.0</version>
8. <executions>
9. <execution>
10. <id>execution1</id>
11. <phase>test</phase>
12. <configuration>
13. <url>http://www.foo.com/query</url>
14. <timeout>10</timeout>
15. <options>
16. <option>one</option>
17. <option>two</option>
18. <option>three</option>
19. </options>
20. </configuration>
21. <goals>
22. <goal>query</goal>
23. </goals>
24. </execution>
25. <execution>
26. <id>execution2</id>
27. <configuration>
28. <url>http://www.bar.com/query</url>
29. <timeout>15</timeout>
30. <options>
31. <option>four</option>
32. <option>five</option>
33. <option>six</option>
34. </options>
35. </configuration>
36. <goals>
37. <goal>query</goal>
38. </goals>
39. </execution>
40. </executions>
41. </plugin>
42. </plugins>
43. </build>
44. ...
45. </project>

The first execution with id "execution1" binds this configuration to the test phase. The second execution does not have a <phase> tag, how do you think will this execution behave? Well, goals can have a default phase binding as discussed further below. If the goal has a default phase binding then it will execute in that phase. But if the goal is not bound to any lifecycle phase then it simply won‘t be executed during the build lifecycle.

Note that while execution id‘s have to be unique among all executions of a single plugin within a POM, they don‘t have to be unique across an inheritance hierarchy of POMs. Executions of the same id from different POMs are merged. The same applies to executions that are defined by profiles.

How about if we have a multiple executions with different phases bound to it? How do you think will it behave? Let us use the example POM above again, but this time we shall bind execution2 to a phase.

1. <project>
2. ...
3. <build>
4. <plugins>
5. <plugin>
6. ...
7. <executions>
8. <execution>
9. <id>execution1</id>
10. <phase>test</phase>
11. ...
12. </execution>
13. <execution>
14. <id>execution2</id>
15. <phase>install</phase>
16. <configuration>
17. <url>http://www.bar.com/query</url>
18. <timeout>15</timeout>
19. <options>
20. <option>four</option>
21. <option>five</option>
22. <option>six</option>
23. </options>
24. </configuration>
25. <goals>
26. <goal>query</goal>
27. </goals>
28. </execution>
29. </executions>
30. </plugin>
31. </plugins>
32. </build>
33. ...
34. </project>

If there are multiple executions bound to different phases, then the mojo is executed once for each phase indicated. Meaning, execution1 will be executed applying the configuration setup when the phase of the build is test, andexecution2 will be executed applying the configuration setup when the build phase is already in install.

Now, let us have another mojo example which shows a default lifecycle phase binding.

1. /**
2. * @goal query
3. * @phase package
4. */
5. public class MyBindedQueryMojo
6. extends AbstractMojo
7. {
8. /**
9. * @parameter expression="${query.url}"
10. */
11. private String url;
12. /**
13. * @parameter default-value="60"
14. */
15. private int timeout;
16. /**
17. * @parameter
18. */
19. private String[] options;
20. public void execute()
21. throws MojoExecutionException
22. {
23. ...
24. }
25. }

From the above mojo example, MyBindedQueryMojo is by default bound to the package phase (see the @phase notation). But if we want to execute this mojo during the install phase and not with package we can rebind this mojo into a new lifecycle phase using the <phase> tag under <execution>.

1. <project>
2. ...
3. <build>
4. <plugins>
5. <plugin>
6. <artifactId>maven-myquery-plugin</artifactId>
7. <version>1.0</version>
8. <executions>
9. <execution>
10. <id>execution1</id>
11. <phase>install</phase>
12. <configuration>
13. <url>http://www.bar.com/query</url>
14. <timeout>15</timeout>
15. <options>
16. <option>four</option>
17. <option>five</option>
18. <option>six</option>
19. </options>
20. </configuration>
21. <goals>
22. <goal>query</goal>
23. </goals>
24. </execution>
25. </executions>
26. </plugin>
27. </plugins>
28. </build>
29. ...
30. </project>

Now, MyBindedQueryMojo default phase which is package has been overrided by install phase.

Note: Configurations inside the <executions> tag differ from those that are outside <executions> in that they cannot be used from a direct command line invocation. Instead they are only applied when the lifecycle phase they are bound to are invoked. Alternatively, if you move a configuration section outside of the executions section, it will apply globally to all invocations of the plugin.

Using the <dependencies> Tag

You could configure the dependencies of the Build plugins, commonly to use a more recent dependency version.

For instance, the Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add <dependencies> element like the following:

1. <project>
2. ...
3. <build>
4. <plugins>
5. <plugin>
6. <groupId>org.apache.maven.plugins</groupId>
7. <artifactId>maven-antrun-plugin</artifactId>
8. <version>1.2</version>
9. ...
10. <dependencies>
11. <dependency>
12. <groupId>org.apache.ant</groupId>
13. <artifactId>ant</artifactId>
14. <version>1.7.1</version>
15. </dependency>
16. <dependency>
17. <groupId>org.apache.ant</groupId>
18. <artifactId>ant-launcher</artifactId>
19. <version>1.7.1</version>
20. </dependency>
21. </dependencies>
22. </plugin>
23. </plugins>
24. </build>
25. ...
26. </project>

Using the <inherited> Tag In Build Plugins

By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could uses the <inherited> tag:

1. <project>
2. ...
3. <build>
4. <plugins>
5. <plugin>
6. <groupId>org.apache.maven.plugins</groupId>
7. <artifactId>maven-antrun-plugin</artifactId>
8. <version>1.2</version>
9. <inherited>false</inherited>
10. ...
11. </plugin>
12. </plugins>
13. </build>
14. ...
15. </project>

Configuring Reporting Plugins

The following is only to configure Reporting plugins in the <reporting> element.

Using the <reporting> Tag VS <build> Tag

Configuring a reporting plugin in the <reporting> or <build> elements in the pom does NOT have the same behavior!

mvn site

It uses only the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element, i.e. site always ignores the parameters defined in the <configuration> element of each plugin specified in <build>.

mvn aplugin:areportgoal

It uses firstly the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element; if a parameter is not found, it will look up to a parameter defined in the <configuration> element of each plugin specified in <build>.

Using the <reportSets> Tag

You can configure a reporting plugin using the <reportSets> tag. This is most commonly used to generate reports selectively when running mvn site. The following will generate only the project team report.

1. <project>
2. ...
3. <reporting>
4. <plugins>
5. <plugin>
6. <groupId>org.apache.maven.plugins</groupId>
7. <artifactId>maven-project-info-reports-plugin</artifactId>
8. <version>2.1.2</version>
9. <reportSets>
10. <reportSet>
11. <reports>
12. <report>project-team</report>
13. </reports>
14. </reportSet>
15. </reportSets>
16. </plugin>
17. </plugins>
18. </reporting>
19. ...
20. </project>

Notes:

1. To exclude all reports, you need to use:
   1. <reportSets>
   2. <reportSet>
   3. <reports/>
   4. </reportSet>
   5. </reportSets>
2. Refer to each Plugin Documentation (i.e. plugin-info.html) to know the available report goals.

Using the <inherited> Tag In Reporting Plugins

Similar to the build plugins, to break the inheritance, you can use the <inherited> tag:

1. <project>
2. ...
3. <reporting>
4. <plugins>
5. <plugin>
6. <groupId>org.apache.maven.plugins</groupId>
7. <artifactId>maven-project-info-reports-plugin</artifactId>
8. <version>2.1.2</version>
9. <inherited>false</inherited>
10. </plugin>
11. </plugins>
12. </reporting>
13. ...
14. </project>

https://maven.apache.org/plugins-archives/maven-jar-plugin-2.6/usage.html

https://my.oschina.net/zh119893/blog/276090