How do plugins add to build phases.
I realize that maven has a list of goals that it executes by default but when we add a plugin node to the
pom.xml,
For example, as per the maven documentation if we include the following plugin
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<configuration>
<models>
<model>src/main/mdo/maven.mdo</model>
</models>
<version>4.0.0</version>
</configuration>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
</plugin>
Q1. What build phase does it tie into by default ?
Q2. Does it get executed in addition to the 'default' goal?, for example if i have a plugin that just echos 'hello'
and it gets tied to the compile phase, do i get a echo of 'hello' in addition to the compilation?
Thanks
Venu
You can see that in the documentation of the plugin which says the java goal is bound to generate-sources.
What you are talking about default goal does not exist. It makes more sense in the meaning of a default binding between maven-plugin:goal and the life-cycle phase in relationship with the packaging type of a project. There you have a kind of default binding which is defined in the Maven super pom which defines the goals and their execution in the life-cyclce.
Related
I've defined a Maven plugin with multiple goals. Currently users run my plugin as follows:
<plugin>
<groupId>myGroupId</groupId>
<artifactId>myArtifactId</artifactId>
<version>someVersion</version>
<executions>
<execution>
<goals>
<goal>myGoal</goal>
</goals>
</execution>
</executions>
</plugin>
but I've seen other plugins, like maven-compiler-plugin and Flyway, that don't require specifying an execution: https://flywaydb.org/getstarted/java
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>5.2.4</version>
<configuration>
<url>jdbc:h2:file:./target/foobar</url>
<user>sa</user>
<locations>
<location>classpath:db/migration</location>
</locations>
</configuration>
</plugin>
How do I specify the goal that should run by default when users exclude the <executions> block?
AFAIK, there are not default goals for Maven plugins.
You can configure a plugin without adding a goal. But this does not execute the plugin.
The plugin must be either executed explicitly on command line (like flyway:migrate) or is executed automatically through the lifecycle (like compile:compile or jar:jar).
I assume you are using the Java5 Annotations to mark your plugin as available mojo? (and not the javadoc way of living).
The #Mojo annotation has a defaultPhase attribute.
Once a user adds the plugin into the build these defaults (if set) will be used.
The Flyway Migrate Mojo does it this way too.
The compiler plugin is a bit of a bad example, as it is part of the default plugin bindings of the maven life-cycle itself. So the phase itself will know what mojo to run.
These are the docs for the maven plugin api, the one for using annotations is nearby.
If it is not your plugin, you can put the configs you want into a parent pom into the pluginManagement section.
I found this description but it does not seem comprehensive. Could someone explain in detail what is the difference between executions and configurations in a maven plugin?
An <execution> causes the plugin to be executed during the maven build lifecycle, i.e. during your build. The <configuration> allows you to configure the plugin for how it should behave during execution. Many Maven plugins provide documentation about their configuration options, e.g. the maven-compiler-plugin.
You can define <configuration>s on the <plugin> level or the <execution> level. The former is globally valid for all executions, the latter is specific to the execution.
Example for global an execution-specific configurations:
Suppose, you have to compile your project with Java 1.7 but you want to early adopt Java 9 Jigsaw features and add a module-info.java to your project. This Java file will not compile using source level 1.7. What you can do is define two executions of the maven-compiler-plugin, one that compiles everything except module-info.java with source level 1.7 and one that does only compile module-info.java with source level 1.9:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<!-- Global plugin configuration for source and target levels. -->
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
<executions>
<!-- Compile all code except module-info.java with the configured source level -->
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<excludes>
<exclude>module-info.java</exclude>
</excludes>
</configuration>
</execution>
<!-- Compile module-info.java with source level 1.9 -->
<execution>
<id>compile-module-info-java</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<source>1.9</source>
<target>1.9</target>
<includes>
<include>module-info.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
I think answer from #Stefan is already quite clear. I would like to be even a bit more verbose in case it helps.
"execution" under plugin is declaring "what should be done at when". Basically, an execution usually at least contains: phase and goal (I know you don't always see it in config, but conceptually they are there), which you can see it as: When the build process reached phase, then the goal action of the plugin will be executed.
Of course, you can have multiple executions for a plugin, so that different/same goals can be run in different/same phases.
Then come to configuration. Sometimes you need to tell the plugin extra detail on how the plugin should act on because the plugin may not be able to guess what you want to do by default. configuration is doing such work. You can refer to document of plugin's goal to see what kind of configuration they accept.
Plugin level configuration will be applied to all executions of the plugin, while you can also define configuration under each execution, which serve as execution-specific configuration. Plugin-level configuration + execution-level configuration is the "real" configuration received by an execution.
A <configuration> section outside an <execution> block affects the plugin's behavior in general way. For instance, plugins that are either executed directly through the CLI or have a default phase that they bind to will use this type of configuration. An example of such a plugin would be the compiler plugin.
On the other hand, a <configuration> section inside an <execution> block only applies to that specific execution.
As always, a more specific configuration can override a general configuration. So if a general configuration (outside an execution block) says <doCheck>false</doCheck>, an execution might choose to only override this by doing <doCheck>true</doCheck>.
Another feature of general configurations is that their parameters will be inherited by all executions of that plugin.
I have a question about maven pom. I have this pom.xml
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>Hello world!</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
when the goal run is executed? Before or after package phase?
(for Maven lifecycle see Maven lifecycle)
Plugin goal is execute after beginning of declared phase (package), and before beginning of next phase (pre-integration-test).
In this scenerio maven command
mvn package
should print Hello World
Multiple executions in one phase:
Note: In Maven 2.0.5 and above, multiple goals bound to a phase are
executed in the same order as they are declared in the POM, however
multiple instances of the same plugin are not supported. Multiple
instances of the same plugin are grouped to execute together and
ordered in Maven 2.0.11 and above).
and
When multiple executions are given that match a particular phase, they
are executed in the order specified in the POM, with inherited
executions running first.
Source: Introduction to the Build Lifecycle
In the case you have given it will be executed in the package phase, cause you explicit defined it to be executed during the package phase. If you like to get it executed before the package phase you need to use the prepare-package phase instead package.
As in title - here is piece of code.
I can have < scope > as well as < phase >
Jbehave documentation doesn't say much about it (http://jbehave.org/reference/stable/maven-goals.html)
<execution>
<id>run-stories</id>
<phase>test</phase>
<configuration>
<!--<scope>test</scope>-->
<includes>
<include>**/*Stories*.java</include>
</includes>
</configuration>
<goals>
<goal>run-stories-as-embeddables</goal>
</goals>
</execution>
The <phase/> element/property is a "standard" Maven property that indicates which phase of the Maven lifecycle the execution will occur in.
The <scope/> element/property you're referring to is specific to the JBehave plugin itself. Per the plugin's documentation, it seems that <scope/> is used to control which "set" of your project's Maven dependencies will be included in the JBehave plugin run. Per this answer on the JBehave site, it seems that, typically, JBehave is executed using only the project's main dependencies and code, not the test dependencies and code.
I am a newbie to Maven . I am reading up Maven - The complete reference and came across the term Plugin Goals under the Build settings category of a pom.xml file :
In this section, we customize the behavior of the default Maven build.
We can change the location of source and tests, we can add new
plugins, we can attach plugin goals to the lifecycle, and we can
customize the site generation parameters.
Can you please explain with an example what is meant by attaching plugin goal to the lifecycle?
A plugin goal is a thing that a plugin does. Attaching a plugin goal to the lifecycle is saying to maven: when you are going through the lifecycle and are in this phase, trigger this plugin to do whatever the plugin does. This might sound rather confusing, so let's go through an example:
I want to deploy my application to the server each time I call mvn install. For this, in the build section of the pom , I add the following configuration:
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.1.1.Final</version>
<configuration>
...
</configuration>
<executions>
<execution>
<id>deploy-jar</id>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Take a look at the execution part: this describes how to attach the deploy goal of the jboss-as-maven-plugin to the install phase of the build lifecycle.
For further explanation of the maven lifecycle and it's phases, read this