In a Maven multi-module project, how can I disable a plugin in one child? - maven

I have a maven multi-module project (boy, I've written that opening way too many times on this site). Almost all the modules (that is, the ones that have code in them) should run the maven-site-plugin to generate reports about code coverage, etc. These have a detailed shared configuration -- which reports to run, which files to cover/exclude for certain plugins, etc.
However, there are a few modules that deal with packaging -- running the assembly plugin to generate a tarball, etc. These gain nothing from running a site report -- there's no code to analyze, no tests to report on.
So I have a lot of modules that need to share plugin configuration, and a few modules that need to not run the plugin, preferably at all. I can do the former (share configuration) if I put the plugin in the <build> section of the parent POM, but I can't seem to turn off the plugin when I need to in this case. I can do the latter (avoid running the plugin) if I push configuration down to each module's own POM, but I can't figure out a good way to share the configuration information in this case.
Is what I want -- shared configuration, for a plugin that's sometimes disabled by a child module -- even possible? If so, how?

By "run the plugin", I'm assuming you mean that the plugin is bound to a lifecycle phase, and you'd like to unbind it in some modules. First, you could consider changing your POM inheritance so that the modules that don't need the plugins have one parent and the ones that do have a different parent. If you don't want to do that, then you can explicitly set the execution phase to "nothing" in a child module. E.g. if you had a parent pom configuration like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>i-do-something</id>
<phase>initialize</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
... lots of configuration
</configuration>
</execution>
</executions>
</plugin>
Then in a child module, you could do this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>i-do-something</id>
<phase/>
</execution>
</executions>
</plugin>
Because it's the same plugin and the same execution id, it overrides the configuration specified in the parent, and now the plugin isn't bound to a phase in the child project.

Ryan Stewart's answer works if execution that you wish to suppress in the parent pom is tagged with an id. If, however, the parent pom doesn't tag the execution with an id (and, of course, you can't edit that parent pom) then I found that doing the following suppresses the parent pom's action.
First set the phase of the execution to none
Create another execution, give it an id and do in it what you need it to do.
run mvn help:effective-pom to confirm that it has correctly suppressed what you needed suppressed from the parent pom.
Here's an example:
This is how my parent pom looked like:
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
<inherited>true</inherited>
</plugin>
I needed to change the goal to jar-no-fork. Note that the execution in parent pom doesn't have an id that I could use to disable it. So here's what added to my child pom:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<phase>none</phase>
</execution>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
As a result this is how the effective-pom looks like:
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<phase>none</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<archive>
<compress>false</compress>
</archive>
</configuration>
</execution>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
<configuration>
<archive>
<compress>false</compress>
</archive>
</configuration>
</execution>
</executions>
<inherited>true</inherited>
<configuration>
<archive>
<compress>false</compress>
</archive>
</configuration>
</plugin>
This ensured that the goal jar never runs and only the goal jar-no-fork executes -- which is what I wanted to achieve.

Related

Generate Javadoc for multimodule project

I have read everything I can find on solving this and my attempts still fail. The best I can do is to get the Javadoc of exactly one module to show up--the last one built. (For now, I'm not trying to bundle Javadoc into any JARs. I'm also not trying to do anything "site".) I just want to put Javadoc for easy access into a subdirectory under the project root.
Here's what's in my parent pom.xml:
<build>
<plugins>
.
.
.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<noqualifier>all</noqualifier>
<reportOutputDirectory>${user.dir}/documents</reportOutputDirectory>
<destDir>javadoc</destDir>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
What I'm putting into subordinate pom.xml files is identical to the above except for
<goals>
<goal>javadoc</goal>
</goals>
I have played with replacing the <execution> in the parent and sometimes subordinate pom.xml files with:
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
but it makes no difference.
I think the following configuration is the reason your reports get overwritten:
<configuration>
<reportOutputDirectory>${user.dir}/documents</reportOutputDirectory>
</configuration>
All module builds will be written to the same directory, hence overwriting the previous build.
The solution is to use the default output directory and configure the output directory for the aggregated javadoc instead. This way the reactor build will create javadoc output files in each module's target directory. These can then be used by the aggregate goal to be combined.
This can be done by configuring your parent POM as follows:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<!-- Default configuration for all reports -->
<noqualifier>all</noqualifier>
<destDir>javadoc</destDir>
</configuration>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
<configuration>
<!-- Specific configuration for the aggregate report -->
<reportOutputDirectory>${user.dir}/documents</reportOutputDirectory>
<destDir>javadoc</destDir>
</configuration>
</execution>
...
</executions>
</plugin>
...
</plugins>
</build>
(there is no need for any additional configuration in the module POM files)
The aggregated javadoc can now be created by running
mvn compile javadoc:javadoc javadoc:aggregate
(note that the compile or package goal is required for reactor to resolve inter-module dependencies)

Running a plugin goal before the default one

TL;DR: Using maven, I want to run a plugin goal at the beginning of the test phase, before tests actually run. What would be a clean way to do it?
I want to print a message just before the tests actually run. Hence I want to use the echo goal of the echo plugin at the beginning of the test phase (to tell the user that if every tests fail, he'd better have a look at the README since there's a test environment he should set up first)
Attempt n°1
A simple approach could be to run this plugin in the previous phase, process-test-classes.
It works, but it doesn't seem semantically correct to bind this task to this phase...
Attempt n°2
According to Maven documentation, 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., so I tried to set explicitly the surefire plugin:
...
<plugin>
<groupId>com.soebes.maven.plugins</groupId>
<artifactId>maven-echo-plugin</artifactId>
<version>0.1</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>echo</goal>
</goals>
</execution>
</executions>
<configuration>
<echos>
<echo>*** If most tests fail, make sure you've installed the fake wiki. See README for more info ***</echo>
</echos>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
...
But tests run before my message is printed.
So, to put it in a nutshell: is there a way to reach my goal, or should I stick to the "process-test-classes solution" even though it seems a bit "hacky"?
Thanks!
As #khmarbaise said, your solution is still hacky, because whole test looks like Integration Test and should be processed by Failsafe Plugin. Failsafe has nice phase pre-integration-test for testing fake wiki etc :)
Based on Guide to Configuring Default Mojo Executions this works for me:
<plugin>
<groupId>com.soebes.maven.plugins</groupId>
<artifactId>maven-echo-plugin</artifactId>
<version>0.1</version>
<executions>
<execution>
<id>1-test</id>
<phase>test</phase>
<goals>
<goal>echo</goal>
</goals>
</execution>
</executions>
<configuration>
<echos>
<echo>*** If most tests fail, make sure you've installed the fake wiki. See README for more info ***</echo>
</echos>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
<executions>
<execution>
<id>default-test</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
<execution>
<id>2-test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
This is very odd for me ;)
I have two plugins with executions bound to generate-sources, one listed first in the list of about 6 plugins and the other listed last. However, the one listed last (which depends on the one listed first) always executes first.
How can I execute several maven plugins within a single phase and set their respective execution order?

Can I modify the Maven deploy phase to replace the maven-deploy-plugin with my own plugin?

I'm pretty new to Maven...
What I'm trying to do is skip the maven-deploy-plugin during the deploy phase, while replacing it with my own plugin (i.e. I'm deploying to a non-repository location).
I realize I could do this in multiple other ways, but the boss wants to be able to run:
mvn deploy
To get the results of my current workaround, which is disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase), and manually specifying the custom upload goal from the command line.
I'm currently failing to succeed in my mission with:
<executions>
<execution>
<phase>deploy</phase>
</execution>
</executions>
in the build/plugins/plugin section containing my plugin specification, since the deploy phase is skipped by:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Thanks!
disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase)
This is not correct. Disabling maven-deploy-plugin doesn't disable the entire deploy phase. This is how it should be done (looks like you're doing it already):
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Try this (untested) alternative for disabling the standard deploy plugin:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>default-deploy</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
I want to build on #yegor256's answer a bit... 8 years, 4 months later!
I found myself here getting into the weeds on some legacy Maven configurations that were full of cruft. Coming from a Maven mindset, albeit some years between now and active hacking, I was re-familiarizing myself with the Maven lifecycle.
TLDR... mvn help:effective-pom is your friend. Use your IDE's tools for viewing the effective POM often (NetBeans makes it easy. I added a keyboard shortcut in IntelliJ.)
In the configuration I was reviewing, the previous developers had created two (2) deploy-file executions, one war, one jar.
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
<execution>
<id>deploy-jar</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
I was aware that these executions would be appended to the default-deploy bound to the deploy phase and observed this behavior in the logs. The default-deploy would run, uploading an empty war file, then the deploy-war would run, uploading, and overwriting, the first war file.
Several options exist.
skip and combine.self="override" (my preference)
As presented, using <skip> as a <configuration> option is viable. It is safe and more portable than setting setting the <phase> to none.
However, it will be inherited by the other executions (certainly as presented). To prevent this, you must explicitly tell your additional <execution> configurations to not inherit.
...
...
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration combine.self="override">
... omitted ...
</configuration>
</execution>
...
...
Override default-deploy
Another option, possibly more verbose and lest esoteric than combine.self="override" is to override the execution of the default-deploy <id> of the plugin.
...
<execution>
<id>default-deploy</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
...
This will not be inherited by the additional <executions>.
Another option
As #yegor256 notes, but in the additional configurations explicitly state <skip>false</skip> to "reset" the inherited <skip> from the plugin.
HTH.

How to register a custom built jar file as maven main artifact?

I have a project expected to deliver a jar file:
<packaging>jar</packaging>
but the jar is built in a custom way, so the default packaging done with jar:jar has been disabled
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
but then when I want to apply shade:shade on the existing jar I get an error
The project main artifact does not exist.
I assume that maven doesn't know about the .jar file created by my custom tool. How to let it know, because antrun attachArtifact doesn't work
<attachartifact file="./bin/classes.jar" classifier="" type="jar"/>
the error I get is
An Ant BuildException has occured: org.apache.maven.artifact.InvalidArtifactRTException: For artifact {:jar}: An attached artifact must have a different ID than its corresponding main artifact.
So this is not the method to register main artifact... Is there any (without writing custom java plugin)?
Thanks,
Lukasz
I checked the sources of JarMojo and it gave me an idea how to solve it with Groovy (via gmaven)
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>set-main-artifact</id>
<phase>package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes.jar"))
</source>
</configuration>
</execution>
</executions>
</plugin>
and it works!:)
Something like this
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${basedir}/bin/classes.jar</file>
<type>jar</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
While your solution may work for a build to the install+ phase or where there are no dependencies in the reactor, in cases where only building to the compile or test phase the unpackaged classes won't be found by dependencies.
Building to compile happens when using plugins like the maven-release-plugin.
Extending your chosen solution to include identifying the unpacked classes during compile
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>set-main-artifact-compile</id>
<phase>compile</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes"))
</source>
</configuration>
</execution>
<execution>
<id>set-main-artifact</id>
<phase>package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes.jar"))
</source>
</configuration>
</execution>
</executions>
</plugin>
By default the maven-install-plugin will use the identified artifact along the lines of
${project.build.directory}/${project.finalname}.jar
So another option might go something like this
<build>
<directory>bin</directory>
<outputDirectory>bin/classes</outputDirectory>
<finalName>classes</finalName>
</build>
We were having the same problem, with getting the "attached artifact must have a different ID than its corresponding main artifact" error. We found the solution in the following excellent blog post:
embed-and-run-ant-tasks-and-scripts-from-maven
As detailed in this section, you can fix the problem by adding a classifier so Maven can distinguish between the ant-built jar and the maven-built jar. Since you're using antrun attachartifact, you'd need this:
<attachartifact file="./bin/classes.jar" classifier="foo" type="jar"/>
Note you'll also need to include that classifier (along with groupId, artifactId and version) whenever you want to grab this jar as a dependency in other projects.

Maven: Extract dependency resources before test

I have a multimodule Maven project. One subproject hosts XSL/XML resource files. The other project hosts Java code that needs to use these files in its unit tests.
In the dependency's jar, the resources lie in the folder xml-resources.
I found this example and tried to change it for my needs:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>resource-dependencies</id>
<phase>process-test-resources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<classifier>xml-resources</classifier>
<outputDirectory>${project.build.directory}/classes/xml-resources</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
This doesn't do anything when I run the process-test-resources phase. Am am sure that there are some errors in there - I do not see where I can specify the dependency the resources should be taken from, and <classifier> does not seem to actually specify the source where the resources should be copied from.
I'm lost here, can somebody tell me how to do this right?
Try something like this
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>resource-dependencies</id>
<phase>process-test-resources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeArtifactIds>my-artifact-id</includeArtifactIds>
<includes>foobar.txt, loremipsum.xml</includes>
<outputDirectory>${project.build.directory}/classes/xml-resources</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Have a look at the unpack-dependencies parameters for detailed explanation or further information.

Resources