Let's say I have 5 different goals linked to Mojos that I want to be able to bind, named from goal-a to goal-e.
I would like to be able to bind them like maven lifecycle phases, i.e. if I define an execution path and I call a goal, all previous goals on this path are executed beforehand.
I would then have :
goal-a -> { goal-b -> goal-d
{ goal-c -> goal-e
So if I run mvn groupdId:artifactId:myPlugin:goal-d, it executes goal-a, goal-b, goal-d.
If i run the same command with goal-e, it executes goal-a, goal-c, goal-e.
Is there any way to define such bindings ?
You can write a custom plugin quite easily that will accomplish what you are looking for using the Mojo Executor.
For instance, you can write a Mojo for goal-d and in it, you can use the Mojo Executor to execute the goal-a and goal-b Mojos.
You can add execution of your plugin into <build> block or create separate profile for its run, and there define all goals. Here is an example:
<build>
<plugins>
<plugin>
<groupId>your.plugin.group.id</groupId>
<artifactId>your-plugin-artifact-id</artifactId>
<executions>
<execution>
<!-- here you need to specify build phase where your plugin execution will be started -->
<phase>install</phase>
<!-- here you can add all your goals to execute -->
<goals>
<goal>goal-a</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
When you execute phase install on project your plugin will execute its goals.
Related
Is it possible to execute same life cycle of two maven plugin if one fails ?
Example:
Let's say I have below plugin configuration,
<plugins>
<plugin>
<groupId>smothing</groupId>
<artifactId>plugin-1</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>doSomthing</id>
<phase>test</phase>
//...//
</plugin>
<plugin>
<groupId>something</groupId>
<artifactId>plugin-2</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>doSomthingAgain</id>
<phase>test</phase>
//...
</plugin>
</plugins>
I would like to execute plugin-2 test phase even if the first plugin fails. I don't want to ignore or skip test cases.
I have below two plugin to be executed same phase even if one fails.
<groupId>com.thoughtworks.gauge.maven</groupId>
<artifactId>gauge-maven-plugin</artifactId>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
Basically, after the gauge tests I want to perform some cleanup activities through maven exec plugin. So is there any option for me to always execute maven exec plugin ? (No command line arguments, something which I am expecting in pom.xml )
I have seen these answers, but everything says to skip test cases.
How to run a maven goal when there is tests failures?
Maven reporting plugins do not execute if a unit test failure occurs
Any help much appreciated :)
If a plugin fails, it'll stop the execution of the lifecycle. So you shouldn't try to solve it by thinking of executing another plugin for some condition.
Based on your description the best approach seems to be writing an extension, see https://maven.apache.org/examples/maven-3-lifecycle-extensions.html . With https://maven.apache.org/ref/3.6.0/maven-core/apidocs/index.html?org/apache/maven/execution/AbstractExecutionListener.html you can see that you can do actions before or after any segment of the lifecycle, e.g. cleaning up after projectSucceeded+projectFailed
We have a use-case where we want to do sonar analysis as part of site generation. That is whenever "mvn install site:site" is invoked, we want sonar:sonar to be invoked as well as part of that.
We tried following plugin configuration, but that doesn't work to execute sonar goal as part of site phase (we tried "pre-site" phase too but that did not work as well):
<build>
<plugins>
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.3.0.603</version>
<executions>
<execution>
<id>sonar-site</id>
<phase>site</phase>
<goals>
<goal>sonar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<build>
Just for experimenting, when we changed: <phase>site</phase> to <phase>post-integration-test</phase> in the above snippet, sonar goal started getting executed after IT execution.
Is there something wrong in compatibility between sonar-maven-plugin and maven-site-plugin. Will appreciate any input or alternate approach to resolve this.
You bound the SonarQube Maven plugin to a site phase, but you didn't execute that phase. You passed site:site which means execute a site goal of the maven-site-plugin.
You have to execute: mvn install site
The solution with post-integration-test works, because that stage is executed by install phase (more or less).
Read more about Maven Lifecycle Reference.
I can use Maven to compile and test a program
mvn compile
mvn test
Is there a lifecycle command to simply run the program, or generate a script which will run the program?
If you are asking this question, it means it's unclear to you what the Maven lifecycle really is.
There is no lifecycle command, only a build lifecycle, which is made up of different phases.
So to make it clear: there is a build lifecycle, which is made up of phases, which are made up of plugin goals.
When you are invoking Maven with
mvn compile
You are invoking a build phase. In Maven, there is a list of predefined ordered phases. When you invoke a phase, all of the phase before it are also invoked. Invoking a phase means that you are invoking all of the plugins that are bound to this phase. For the compile case, this means it will, among others, invoke the maven-compiler-plugin wich is bound to the compile phase by default.
So to answer your question strictly: no, there is no lifecycle command to do that.
However, you can configure a plugin in your POM, which will be bound to a certain phase, and invoke that phase. For that, you can refer to #manouti's answer which introduces the exec-maven-plugin.
There is no lifecycle phase to do this but you can bind the exec-maven-plugin, specifically the exec:java goal to it. For example, to run the goal on the package phase:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>run-java</id>
<phase>package</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>main.Class</mainClass>
</configuration>
</plugin>
I have a Maven project which includes a Maven plugin (the Liquibase Maven plugin) which exposes different goals.
Two of these goals (update and diff) need different parameters which are in conflict between them (because the semantics of the two is different), so I need to give Maven different properties in the two goal executions.
That's what I've done
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>3.4.1</version>
<!-- This configuration is used for every goal except "diff" -->
<configuration>
<propertyFile>src/main/resources/liquibase.properties</propertyFile>
<promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
</configuration>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>diff</goal>
</goals>
<!-- This configuration is used for the "diff" goal -->
<configuration>
<propertyFile>src/main/resources/liquibaseDiff.properties</propertyFile>
<promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
</configuration>
</execution>
</executions>
</plugin>
However, this configuration is wrong because for each goal (diff, update of the others) only the liquibaseDiff.properties file is used.
Is there any way to pass different configurations for different goals in Maven?
Configuration of plugins can be done in two different locations:
Globally for all executions. The global configuration is done with the <configuration> element under <plugin>. This configuration in inherited by all executions.
Per execution. This is done using the <configuration> element under <execution>.
In your example, consider this POM:
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>3.4.1</version>
<configuration>
<!-- put the configuration here that is common to all executions -->
</configuration>
<executions>
<execution>
<id>diff</id>
<goals>
<goal>diff</goal>
</goals>
<configuration>
<!-- put the specific configuration of the diff goal here, this will inherit from the global configuration -->
</configuration>
</execution>
<execution>
<id>update</id>
<goals>
<goal>update</goal>
</goals>
<configuration>
<!-- put the specific configuration of the update goal here, this will inherit from the global configuration -->
</configuration>
</execution>
</executions>
</plugin>
The default inheritance behavior is to merge the content of the configuration element according to element name. If the child POM has a particular element, that value becomes the effective value. If the child POM does not have an element, but the parent does, the parent value becomes the effective value.
In case of conflicts, you can control the default inheritance performed by Maven using combine.children and combine.self. Quoting the Maven docs:
combine.children="append" results in the concatenation of parent and child elements, in that order. combine.self="override", on the other hand, completely suppresses parent configuration.
In addition to this, you need to be aware that when executing a Maven command, on the command line, that directly invokes a goal, such as mvn liquibase:diff, it creates a new execution with an id that is default-cli. As such, since the specific configuration above of the goal diff is done in an execution with id diff, it will not be used. This is actually normal, since the same goal of the same plugin could be present in multiple execution blocks with different configuration: which one should be used if it is executed on the command line, without additional information?
Typically, this situation is solved in 2 manners:
Execute on the command line a specific execution, i.e. the one you configured. This is possible since Maven 3.3.1 and you would execute
mvn liquibase:diff#diff
The #diff in the command above refers to the unique <id> of the execution that is configured in the POM.
Bind your execution to a specific phase of the Maven lifecycle, and let it be executed with the normal flow of the lifecycle. This is generally the prefered solution. In the example above, we could, for example, add a <phase>test</phase> in the execution block of the diff execution; and then Maven will execute it when the test phase is ran during the course of the build.
I'm looking at the plugin section of a pom I'm inspecting and found this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>pre-site</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
If you observe the execution section you will notice that it does not have an id tag. My question is how is the id tag used by Maven and how the absence of one influences the observed behavior. I looked into Maven tutorials and could infer that id's of different execution phases must be unique, in a pom not necessarily across the inherited poms, but it did not mention how it is utilized.
For Maven 3.0.x at least, when not specified, the ID for an execution is default-goalName. So for the example you have, the ID would be default-check. The value default-cli may also be used to configure command line executions.
The execution IDs are used when creating the effective POM from the POM itself, any parent POMs (including the Maven super POM), and settings.xml. Maven merges configuration for plugin executions having the same ID across these POMs. Here's an example. Assume this plugin config is in a parent POM (only Maven super POM is higher up in the hierarchy.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<!-- default-jar is the ID assigned to the jar:jar execution
included automatically by Maven. This demonstrates how we
can tweak the built-in plugin executions to meet our needs.
Note we do not have to specify phase or goals, as those are
inherited. In the example we add a configuration block and
change the values of the <forceCreation> and <finalName>
elements. -->
<execution>
<id>default-jar</id>
<configuration>
<finalName>firstJar</finalName>
<forceCreation>true</forceCreation>
</configuration>
</execution>
<!-- Add an execution of the jar plugin to build a jar with the
same contents but different name. We assign an execution ID.
Because we are not inheriting config for this execution it's our
responsibility to specify phase and goals, as well as the config
we want. Executions are run in order so this one will run after
the default. -->
<execution>
<id>another-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<finalName>duplicateJar</finalName>
</configuration>
</execution>
<!-- Configure plugin behavior if we execute the jar:jar goal
directly from the command line. Don't bind this to a phase;
we don't want to run this as part of the normal lifecycle. -->
<execution>
<id>default-cli</id>
<configuration>
<finalName>cmdLineJar</finalName>
</configuration>
</execution>
</executions>
</plugin>
With the above config:
mvn clean package - builds firstJar.jar and duplicateJar.jar
mvn jar:jar - builds cmdLineJar.jar (note, no clean lifecycle!)
mvn clean jar:jar - removes target dir, builds empty (except for manifest) cmdLineJar.jar; because jar:jar does not run the full lifecycle, just one goal
mvn clean prepare-package jar:jar - runs lifecycle thru prepare-package, then builds a non-empty cmdLineJar.jar
The problem can not be treated with respect to id tag only but notice the different values of it through the examples. This has been tested with maven 3.0.5. Consider the following pom part:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>some-other-other-id</id> <!-- No goal for execution is defined -->
<phase>pre-site</phase>
</execution>
<execution>
<phase>pre-site</phase> <!-- No id for execution is defined -->
<goals>
<goal>check</goal>
</goals>
</execution>
<execution>
<id>some-id</id> <!-- No phase for execution is defined -->
<goals>
<goal>check</goal>
</goals>
</execution>
<execution>
<id>some-other-id</id> <!-- Both id and phase defined -->
<phase>pre-site</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
When run mvn clean site from command line it outputs the following:
[INFO] --- maven-docck-plugin:1.0:check (default) # MavenJavaApplication ---
[INFO] Skipping unsupported project: MavenJavaApplication
[INFO] No documentation errors were found.
[INFO]
[INFO] --- maven-docck-plugin:1.0:check (some-other-id) # MavenJavaApplication ---
[INFO] Skipping unsupported project: MavenJavaApplication
[INFO] No documentation errors were found.
Notice that the execution outputs are always in form of:
<plugin-name>:<plugin-version>:<phase> (<execution-id>)
Case 1: No goal for execution is defined
From Build lifecycle basics:
A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. (...) Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.
From Guide to configuring plugins: Configuring build plugins:
But if the goal is not bound to any lifecycle phase then it simply won't be executed during the build lifecycle.
From what is quoted, it may be concluded that the execution with id some-other-other-id can be ran from the command line, but that is not so, it can never be ran - it will be covered in the 5th example.
Case 2: No id for execution is defined
The definition of goal and a phase in the first execution is enough for it to get run so it gets assigned a default execution id of value default and it gets executed.
Case 3: No phase for execution is defined
Since the phase is not defined anywhere this execution does not get executed. It can be verified by the fact that the output does not contain the line with its execution id.
Case 4: Both id and phase defined
This execution defines all three: an id, a phase and a goal so it gets executed.
Case 5: CLI execution
If you run (read the syntax in the docck plugin documentation):
mvn docck:check -Doffline=true
it will output:
[INFO] --- maven-docck-plugin:1.0:check (default-cli) # MavenJavaApplication ---
From Guide to configuring default mojo executions:
Starting in Maven 2.2.0, each mojo invoked directly from the command line will have an execution Id of default-cli assigned to it, which will allow the configuration of that execution from the POM by using this default execution Id
You can provide the properties for the goal executed from CLI in three different ways:
in the command line directly
in the plugin configuration
in the execution tag with id of value default-cli
Specifically, the above command is equivalent of running
mvn docck:check
with the pom containing:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<configuration>
<offline>true</offline>
</configuration>
</plugin>
or:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>default-cli</id>
<phase>pre-site</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<offline>true</offline>
</configuration>
</execution>
</executions>
</plugin>
This last part comes in handy if you want to keep the global configuration for some common properties in different executions, but you want a complete other set of properties for running from CLI.
Case 6: The default execution
Since the maven-docck-plugin has no default binding I'll cover it with the maven-compiler-plugin. Consider an empty pom with jar packaging. If you run:
mvn clean install
it will trigger the compile phase also and you will see in output:
[INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) # MavenJavaApplication ---
To cover the value of the id tag, from Guide to Configuring Default Mojo Executions:
Likewise, each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of default-<goalName> assigned to it, to allow configuration of each default mojo execution independently.
If you run mvn help:effective-pom you will find the default execution definition for compiler plugin in output:
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
It gets inherited from super POM for the jar packaging type:
When no packaging is declared, Maven assumes the artifact is the default: jar. The valid types are Plexus role-hints (read more on Plexus for a explanation of roles and role-hints) of the component role org.apache.maven.lifecycle.mapping.LifecycleMapping. The current core packaging values are: pom, jar, maven-plugin, ejb, war, ear, rar, par. These define the default list of goals which execute to each corresponding build lifecycle stage for a particular package structure.
In other words, the above default execution definition is the consequence of a default lifecycle mapping (documentation, definition ) for the compiler-plugin:
The Compiler Plugin has two goals. Both are already bound to their proper phases within the Maven Lifecycle and are therefore, automatically executed during their respective phases.
compiler:compile is bound to the compile phase and is used to compile the main source files.
Uniqueness of an execution id tag
From Guide to configuring plugins.html: Using the executions tag:
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.