Develop Reference

Skip running PITest in maven build

I'm trying to run a maven build from command line and exclude PITest from running any mutations. Currently the reports are failing and we need to be able to give a parameter to ignore running the mutation tests or ignore the results and continue the build
I've running with some parameters like mvn package -Dpit.report=true
or mvn package -Dmaven.report.skip=true
This is the PITest setup in my pom
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>1.1.10</version>
<configuration>
<timestampedReports>false</timestampedReports>
<mutationThreshold>95</mutationThreshold>
</configuration>
<executions>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>mutationCoverage</goal>
</goals>
</execution>
</executions>
</plugin>
The problem is that is is still running PITest and causing the build to fail

There is no native way of skipping a plugin execution, but there are least 2 workarounds:
First, is adding a property to override execution phase:
Define a property pitPhase with default value as the default phase of plugin execution.
Then in plugin configuration:
<execution>
<phase>${pitPhase}</phase>
...
</execution>
After that, when you want to skip execution mvn -DskipPit=pitPhase package
The other alternative is to add a Maven profile with the plugin execution

The execution of Pitests can be skipped in Maven.
In your pom.xml:
Set in general properties:
<properties>
<pitest.execution.skip>true</pitest.execution.skip>
</properties>
Set in the plugin:
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>Your_Version</version>
<configuration>
<skip>${pitest.execution.skip}</skip>
</configuration>
</plugin>

Since 1.4.11 there is the option skipPitest. See here: https://github.com/hcoles/pitest/releases/tag/pitest-parent-1.4.11
So you do: -DskipPitest

Cannot execute Groovy Maven Plugin as a goal

I am using Apache Maven 3.3.9 with the Groovy Maven plugin. Here is the relevant section of the pom.xml (the inlined Groovy script is just fictional):
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<id>myGroovyPlugin</id>
<phase>prepare-package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
log.info('Test message: {}', 'Hello, World!')
</source>
</configuration>
</execution>
</executions>
</plugin>
If I am calling mvn install the inline Groovy script gets called by the plugin as part of the prepare-package phase and works just fine. But if I try to call the plugins' goal directly via mvn groovy:execute I get the following error message:
[ERROR] Failed to execute goal org.codehaus.gmaven:groovy-maven-plugin:2.0:execute (default-cli) on project exercise02: The parameters 'source' for goal org.codehaus.gmaven:groovy-maven-plugin:2.0:execute are missing or invalid -> [Help 1]

The error you are getting is already pointing at the issue: the plugin couldn't not find the source configuration option because indeed it is only configured within the myGroovyPlugin execution, that is, only in the execution scope and not as a global configuration.
This is the main difference between configuration element outside the executions (global configuration for all executions of the plugin (even from command line) and within an execution (configuration only applied to that particular goal execution).
To fix the issue you should move the configuration element outside the executions section in this case, since the plugin is not a plugin invoked during default bindings by Maven, it would be enough and not have impact on your build: it will be still used during the myGroovyPlugin execution AND from explicit executions from command line.
From Maven POM reference, the configuration within an execution:
confines the configuration to this specific list of goals, rather than all goals under the plugin.
To make it clear, you should change it to the following:
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<id>myGroovyPlugin</id>
<phase>prepare-package</phase>
<goals>
<goal>execute</goal>
</goals>
</execution>
</executions>
<configuration>
<source>log.info('Test message: {}', 'Hello, World!')</source>
</configuration>
</plugin>
As such the configuration will become a global configuration and applied to both command line executions and declared executions.
Since you are using Maven 3.3.9, you could also make use of a slightly more verbose pattern to invoke directly a specific configuration of an execution:
mvn groovy:execute#myGroovyPlugin
This pattern is useful in cases where you really don't want a global configuration because you don't want to impact other (often default) executions of a certain plugin and you really want to use a specific isolated configuration both in an execution and from command line.

Maven: run plugin twice during a phase, interleaved with another plugin

For our end-2-end test we need to execute the following logical flow:
Create and set up e2e schema (user) in the database (pre-integration-test)
Run Liquibase to initially populate the schema (pre-integration-test)
Add e2e-specific test data to the DB tables (pre-integration-test)
Start Tomcat (pre-integration-test)
Run the web application in Tomcat (integration-test) using Protractor
Shut down Tomcat (post-integration-test)
Clean up the DB: drop the schema (post-integration-test)
For running SQL the sql-maven-plugin is used, however this flow doesn't fit the regular POM layout:
The SQL plugin has to run during pre-integration-test twice, before and after the liquibase-maven-plugin
The SQL plugin has to run before Tomcat plugin during pre-integration-test, however it has to run after during post-integration-test, so that the DB schema is dropped after Tomcat has shut down.
As far as I could conclude from Maven docs, the order of plugins in the POM defines the order of execution during the same phase, and a plugin cannot be mentioned twice in the same POM.
Question: Is there any way to achieve this, apart from writing a shell script that would invoke Maven multiple times?
P.S. found a similar unanswered question.

Given the sample POM below:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.sample</groupId>
<artifactId>sample-project</artifactId>
<version>0.0.2-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>print-hello</id>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo message="hello there!" />
</target>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.5.0</version>
<executions>
<execution>
<id>exec-echo</id>
<phase>validate</phase>
<configuration>
<executable>cmd</executable>
<arguments>
<argument>/C</argument>
<argument>echo</argument>
<argument>hello-from-exec</argument>
</arguments>
</configuration>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>print-hello-2</id>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo message="hello there 2!" />
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
We are actually configuring:
The maven-antrun-plugin to print the hello there! message
The exec-maven-plugin to print the hello-from-exec message
The maven-antrun-plugin to print the hello there 2! message
Goal executions are all attached to the same phase, validate, and we would expect to be executed in the same defined order.
However, when invoking (the -q option is used to have exactly and only their output):
mvn validate -q
we would have as output:
main:
[echo] hello there!
main:
[echo] hello there 2!
hello-from-exec
That is, for the same phase, Maven executed the defined plugins, however merging all of the defined executions for the same plugins (even if defined as different plugin sections) and then execute them in the order to merged definitions.
Unfortunately, there is no mechanism to avoid this merging. The only options we have for configuring plugins execution behaviors are:
The inherited configuration entry:
true or false, whether or not this plugin configuration should apply to POMs which inherit from this one. Default value is true.
The combine.children and combine.self to
control how child POMs inherit configuration from parent POMs by adding attributes to the children of the configuration element.
None of these options would help us. In this case we would need a kind of merge attribute on the execution element or have a different behavior by default (that is, Maven should respect the definition order).
Invoking the single executions from command line as below:
mvn antrun:run#print-hello exec:exec#exec-echo antrun:run#print-hello-2 -q
We would instead have the desired output:
main:
[echo] hello there!
hello-from-exec
main:
[echo] hello there 2!
But in this case:
We are not attached to any phase
We are invoking directly specific executions (and their configurations) via command line (and via a new feature only available since Maven 3.3.1
You can achieve exactly the same via scripting or via exec-maven-plugin invoking maven itself, but - again - the same would apply: no phase applied, only sequence of executions.

How to specify JAR location of a Maven dependency as plugin parameter?

I've tried to follow the configuration from this response on SO to use the jar location in my local repo as a plugin parameter, but it doesn't seem to work. I don't know if this due to a newer Maven version than the response (I'm using Maven 3.2.5).
In my pom.xml, I need to add a javaagent to my surefire plugin definition. The javaagent jar file is a dependency in my project.
I have tried the following:
<dependencies>
<dependency>
<groupId>org.jmockit</groupId>
<artifactId>jmockit</artifactId>
<version>${jmockit.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
...
<!-- Configuration to use jmockit on IBM J9 -->
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-javaagent:${org.jmockit:jmockit:jar}</argLine>
</configuration>
</plugin>
I was expecting that the ${org.jmockit:jmockit:jar} would be expanded to the location of the jar, but in my mvn console I see the following error:
[ERROR] Command wascmd.exe /X /C "C:\IBM\SDP\jdk\jre\bin\java -javaagent:${org.jmockit:jmockit:jar} -jar C:\dev\Eclipse\rtc-connector\target\surefire\surefirebooter1389906134960134.jar C:\dev\Eclipse\rtc-connector\target\surefire\surefire5488684370604495471tmp C:\dev\Eclipse\rtc-connector\target\surefire\surefire_05402037720997438783tmp"
So obviously the parameter is not getting expanded. I was hoping/expecting to see something like -javaagent:c:\users\eric\.m2\repository\org.jmockit\1.20\jmockit-1.20.jar or something similar.
Is there a clean way I can reference the jar from my dependency in my plugin configuration? I know I can use the dependency-plugin to copy the jar to a known location in my target folder and then point to that, but I was hoping there would be an easier solution that doesn't require the intermediary step.

To be variable expanded need to add maven-dependency-plugin:
<!-- obtain ${*:*:jar} properties -->
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>getClasspathFilenames</id>
<goals>
<goal>properties</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-javaagent:${org.jmockit:jmockit:jar}</argLine>
</configuration>
</plugin>

You need to set the "argLine" tag value as follow :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire.version}</version>
<configuration>
<argLine>
-javaagent:"${localRepository}/org/jmockit/jmockit/${jmockit.version}/jmockit-${jmockit.version}.jar"
</argLine>
</configuration>
</plugin>
You need to set the .m2 repo path where the jmockit jar is present. It's working for me.

The maven-dependency-plugin contains a goal build-classpath which would solve this problem.
On command line you can do things like this:
mvn dependency:build-classpath -DincludeArtifactIds=testng -DincludeGroupIds=testng
which results in:
C:\repository\org\testng\testng\6.8.21\testng-6.8.21.jar
The resulting classpath can also be put into a property outputProperty ....
This could be configured into pom as well...

Mechanics of Goal execution in Maven

I have the wsimport plugin in my project.
I would like to execute the wsimport. According to the website, the string to execute is "mvn jaxws:wsimport".
Firstly, is this string deductable from the XML ?
The artifact ID is :
<artifactId>jaxws-maven-plugin</artifactId>
and goal :
<goal>wsimport</goal>
so is the artifact-part just the substring of the artifactid leading up to "-maven-plugin" ?
..And when I execute my plugin goal "mvn jaxws:wsimport" does this completely ignore which phase I am in? Ie. is this running outside of the phase? And if no, is there a way to run this standalone?
ie. is there a way I can set the phase to none? (eg [phase]none[/phase]).
Pom code :
<build>
<plugins>
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<id>wsimport-from-jdk</id>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<executable>${tool.wsimport}</executable>
<wsdlUrls>
<wsdlUrl>http://WorkPC:8080/server-web/AirlineWS?wsdl</wsdlUrl>
</wsdlUrls>
<packageName>com.bluewalrus</packageName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

When you issue a command like mvn [plugin]:[goal], it launches Maven out of any lifecycle, so if you do not intend to perform that goal inside a lifecycle, but only via such commands, you shouldn't have any <execution> defined, just place <configuration> right after <version>.
About how Maven can shorten the plugin call (i.e. mvn dependency:tree instead of mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:tree), it is based on several conventions:
When no version defined, it tries to take the latest from available repositories
When the groupId is omitted, it looks among the predefined or user-defined pluginGroups to find a suitable one. See here for more information (Configuring Maven to Search for Plugins)
On the same page, you can see how plugins prefixes are used to shorten the plugin prefix, by using a prefix instead of the artifactId of the plugin. Thirdparty plugins should use [prefix]-maven-plugin construction, and it looks OK here.
And to disable the default execution of a plugin (although it might not be useful in this case), you can use this answer