Running maven-shade and dockerfile-maven in different phases - maven

My app uses maven-shade-plugin to pack things into single fatjar and then I would like to build a docker image using dockerfile-maven-plugin, my problem is that I can set the pom file properly so it would work.
What happens is that the docker plugin runs before the jar file was created...
I've tried to force the jar creation on prepare-package and the docker image build on package but it didn't work as expected...
any ideas?
EDIT: added pom snippet
<build>
<plugins>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<version>${dockerfile-maven.version}</version>
<configuration>
<repository>test-docker-image</repository>
<tag>${docker.tag}</tag>
<buildArgs>
<JAR_FILE>${project.artifactId}-${project.version}-fat.jar</JAR_FILE>
<CONFIGURATION_FILE>configuration.json</CONFIGURATION_FILE>
</buildArgs>
</configuration>
<executions>
<execution>
<goals>
<goal>build</goal>
<!-- <goal>push</goal> -->
</goals>
<phase>install</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>${maven.shade.plugin.version}</version>
<executions>
<execution>
<goals>
<goal>shade</goal>
</goals>
<phase>package</phase>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<manifestEntries>
<Main-Class>io.vertx.core.Launcher</Main-Class>
<Main-Verticle>MyVerticle</Main-Verticle>
</manifestEntries>
</transformer>
</transformers>
<minimizeJar>false</minimizeJar>
<outputFile>${project.build.directory}/deploy/${project.artifactId}-${project.version}-fat.jar</outputFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

I had both of these same plugins listed in the same order you have (docker-maven-plugin before maven-shade-plugin) and was seeing the same issue. I discovered that Maven executes plugins in the same phase in the order that they are listed, so moving maven-shade-plugin to be first resolved the issue for me locally. (Older versions of Maven don't order plugins this way, so use the latest if possible.)
This doesn't explain why it is not working for you when you change them to use different phases, but I'd suggest at least trying it out that reordering. Also be sure that you are using the latest versions of related plugins, like maven-release-plugin.
I was still seeing the undesired behavior in my build environment after doing all of the above, due to the parent of my project containing an execution for docker-maven-plugin; the fact that I was customizing it and reordering it in my own project didn't help, although it is unclear why it worked locally. Maven build profiles can also have a similar impact on ordering. My solution there was to bind the docker-maven-plugin:build execution to the install phase.
The output of mvn help:effective-pom should let you see the exact listing of plugins, executions, and profiles so that you can see exactly what the ordering will be for your project. Note that profiles are executed bottom-to-top, which is the opposite of plugins!

Related

Maven executing configured plugin

Under Maven version 3.0.4 I have the problem to specify the execution of a single configured plugin. Say I have two different configured maven-antrun-plugins. Both are in the same lifecycle. How can I target the plugin I want to execute without using different lifecycles?
Since version 3.3.1 it's possible to do it in this form: mvn groupid:artifactid:goal#id
Is there a way to do this in a similar way in version 3.0.4 or lower?
You can use the "default-" in your pom to have the first plugin running during the default lifecycle (since Maven 2.2.0), and use a classifier for the second plugin, for example with the maven jar plugin, you can see the example below:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>default-jar</id>
<configuration>
<excludes>
<exclude>**/somepackage/*</exclude>
</excludes>
</configuration>
</execution>
<execution>
<id>special-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<includes>
<include>**/sompackage/*</include>
</includes>
<classifier>somepackage</classifier>
</configuration>
</execution>
</executions>
</plugin>

Redirecting the nexus-staging-maven-plugin to an internal repository

I have a webjars project that I'd like to build snapshots and have them deployed locally (within our infrastructure) but have the releases be managed by webjars.org.
https://github.com/webjars/oscar/blob/15.0.0-RC1/pom.xml
The problem I'm facing is that they need the nexus-staging-maven-plugin defined as part of their release process. So I'd like to keep the POM tailored for them as much as possible, and just make our own deviations via command line (or worst case, profile) if possible.
Typically, if doing this from scratch, you'd probably introduce the staging plugin in a profile, but I don't think I have that option. (I might have to make the modification though and discuss it with them.)
I've never used the staging plugin before, so this is my first exposure and it isn't a pleasant one given what I'm trying to do. I feel like I'm fighting the system.
I thought I had something by specifying:
-DsonatypeOssDistMgmtSnapshotsUrl=http://myurl
and that pushes the artifact at the correct location, but then I can't figure out how to supply credentials. (401 unauthorized) I thought specifying the serverId might work, but no.
-DserverId=public-snapshots
http://books.sonatype.com/nexus-book/reference/staging-deployment.html
I then tried creating a profile, where I'd do something like this:
<profile>
<id>disable-staging</id>
<build>
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.5</version>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</plugin>
</plugins>
</build>
</profile>
but that doesn't help. The effective-pom shows this:
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.5</version>
<extensions>true</extensions>
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</execution>
</executions>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</plugin>
and I can't unbind the deploy phase.
I'm wondering if anyone has any ideas on what to do in this type of scenario?
You can use the Nexus Staging Plugin's property skipNexusStagingDeployMojo to achieve this:
mvn clean package deploy:deploy -DskipNexusStagingDeployMojo=true
-DaltDeploymentRepository=snapshots::default::https://my.nexus.host/content/repositories/snapshots-local
It is important to explicitly invoke package and then deploy:deploy, as otherwise (when only invoking mvn deploy) the default execution of the maven-deploy-plugin is suppressed by the Nexus Staging Plugin (even with the skip set to true).

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.

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

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.

Maven-release-plugin and builder-helper plugin

I guess i am missing something.. I want to make a release of my project. I added maven-release-plugin to my pom. In addition, i have another source code dir aside from java(call it gen-src). When i make the first steps in the maven release (i.e prepare) everything is ok, but when i make perform it does not take the gen-src in account.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/gen_src</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
I suspect that it may be connected to the fact that the phase is generated-sources. Do i need to attach the add-source goal to another phase? If yes, how?
I also read in here - this is similar problem though i am not using flex..no answer.
Any idea?Thanks.
I had the same problem in the past and I think I know what's happening. The release:perform phase checkouts a copy of the tag to be released to 'target/checkout' folder and fork a maven process to build this checkout. As you have a problem only in the release:perform phase, it must be related to the fact that maven in running a fork process on the 'target/checkout' folder, not in the './' folder.
I ended up fixing this problem removing build helper, but I don't know if you could do the same, so if I were you I would try avoiding relative paths on configurations. You can configure the build-helper like that:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/src/main/gen_src</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
Defining explicitly the ${basedir} could avoid this problem because ${basedir} will resolve to the fork path (your_workspace/project/target/checkout) instead of the current path (your_workspace/project). If this doesn't fix the problem, I believe we should file a bug against build-helper-maven-plugin because there should be no errors only in the perform phase.
The generated source classes won't make it into the binary jar — there you'll find only .class files resulting from compilation of both regular and generated sources. Maven release plug-in will, though, include the extra source directory into sources jar.
There is no need to execute "add-source" goal in any other phase; what you could find useful is letting the clean plug-in know that it should include the extra directory:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<filesets>
<fileset>
<directory>${basedir}/src/main/gen_src</directory>
<includes>
<include>**/*</include>
</includes>
</fileset>
</filesets>
</configuration>
</plugin>

Resources