I have a project with a parent directory containing the following in its pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.20.1</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
and
<modules>
<module>submodule</module>
</modules>
The submodule subdirectory again contains a pom.xml with a reference to its parent artifact. The subdirectory also contains a number of integration tests which run fine if I move the failsafe plugin into the submodule's pom.xml and then invoke mvn verify from the parent directory but this will not work with this current (preferred) setup (There are no errors, the tests are simply not executed).
I've tried adding the submodule artifact to dependenciesToScan in the failsafe plugin's configuration but that did not solve the problem. Do I need to add the submodule as a dependency in the parent pom.xml? Because that results in a "dependency is referencing itself" error while processing the pom.xml.
Help would be appreciated.
EDIT: I have figured it out, someone else working on the project had wrapped the build section in a profile section, I did not realise this at first because the whole file is rather large and unwieldly and I had overlooked the corresponding git commit. By undoing that change and following the instructions in the link posted by Gerald Broser I managed to solve my problem (I suppose just executing the respective profile would have also done it, but that change was uncalled for anyway).
See Maven Failsafe Plugin / Usage / Usage in multi-module projects:
When you are defining a shared definition of the Failsafe Plugin in a parent pom, it is considered best practice to define an execution id in order to allow child projects to override the configuration.
try to call
mvn clean verify -P <module>
Related
I have a project with finalised version in pom files , lets say 12.3.45 .
I have built the code for this version some time ago already, all the built jars are in the local maven repo.
Then at some point I have run mvn clean, so all the target folders are being removed.
And now I want to execute some code, as quickly as possible, using mvn exec:java. Preferably without building anything, because why not? all the jars at some point were already built, and I know there were no code changes after that. How can I force maven to execute the code as fast as possible , not recompile anything, and just reuse the jars from the local repo?
Thanks.
If your artifacts are in a local or remote repository you can use them as dependencies.
You can use exec-maven-plugin's options includeProjectDependencies or includePluginDependencies to use them in java execution
https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#includePluginDependencies. includeProjectDependencies option is enabled (true) by default.
You can execute exec-maven-plugin without building anything with mvn exec:java command
Instructions:
To run exec-maven-plugin you would need a main class to run. I assume you have one in your project. If you don't - you need to make a separate project with a main class.
Create a blank maven project.
In the project add exec-maven-plugin configuration. Set the mainClass
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<goals>
<goal>java</goal>
</goals>
<configuration>
<mainClass>pack.App</mainClass>
</configuration>
</plugin>
</plugins>
</build>
Include you artifacts as dependencies to the project
<dependencies>
<dependency>
<groupId>my.group</groupId>
<artifactId>myartifact</artifactId>
<version>12.3.45</version>
</dependency>
</dependencies>
Run mvn exec:java to execute com.my.package.MyMainClass main class from my.group.myartifact artifact
Edits:
includeProjectDependencies option is enabled (true) by default
I have a Maven Scala project that will be deployed on some container and therefore mark several of the dependencies with scope provided meaning those dependencies will be used for compiling but not taken into account for transitive resolution as they are "provided at runtime". However, when I run the following command, it produces the intended jar with dependencies but also including those dependencies that were marked as provided.
mvn clean install assembly:assembly -DdescriptorId=jar-with-dependencies -DskipTests
I tried existing answers to this problem e.g. Excluding “provided” dependencies from Maven assembly but for some reason produces an incorrect choice of dependencies and even missing the main code. In this OP I'd like to find a cleaner, more up to date solution to this problem ... is there one?
You may be better off with a different maven plugin. See Difference between maven plugins ( assembly-plugins , jar-plugins , shaded-plugins. Shade would probably suit you best in this case. What you are looking to create is referred to an uber-jar.
Regarding Shade, from the Maven website:
This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.
The goals for the Shade Plugin are bound to the package phase in the build lifecycle.
Configuring Your Shade Plugin:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<!-- put your configurations here -->
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
Note that the default implementation replaces your project's artifact with the shade version. Need both? Look here: Attaching the Shaded Artifact
Merging several jars at once is not necessarily utter simplicity and so Shade has the concept of Resource Transformers (link also has more samples).
Aggregating classes/resources from several artifacts into one uber JAR is straight forward as long as there is no overlap. Otherwise, some kind of logic to merge resources from several JARs is required. This is where resource transformers kick in.
The project site is actually quite good. There are lots of varied examples.
I have a multimodules project:
parent
|____ module1
|____ module2
|____ module3
I want to generate aggregated Javadoc for all the modules. This works by using something like this in the parent's pom.xml (which has a pom packaging and defines the children modules):
//...
<modules>
<module>module1</module>
<module>module2</module>
<module>module3</module>
</modules>
//...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.3</version>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
<phase>prepare-package</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
The aggregated Javadoc is generated correctly, that works well!
But the problem is that I need to include the generated aggregated Javadoc in the module3 final .jar! In other words, I want the resulting module3.jar to contain a copy of that generated aggregated Javadoc of all the modules!
That's why I try to run the maven-javadoc-plugin plugin at the prepare-package phase in the parent project: I'd like the Javadoc to be generated before the packaging of module3 is done, so I can include it (by copying it using a maven-antrun-plugin plugin, for example).
But, and here's my problem, it seems that even if I use the prepare-package phase, the aggregated Javadoc is not generated yet when the package phase is run for the module3 artifact! It's like if the parent plugin is run after all the children plugins, even if it is declared using a phase which is supposed to be run before...
Any idea on how I could generate the aggregated Javadoc for all the modules before the package phase of the module3, so I can include that Javadoc?
I wish someone finds a better solution, but here's the workaround I did, if it can help someone one day:
I do not let Maven generate the aggregated Javadoc by itself. I prevent that by wrapping the maven-javadoc-plugin plugin in a <profile>. I gave an "aggregatedJavadoc" id to mine.
Then, in module3's pom.xml, I added a exec-maven-plugin plugin that, ultimately, programatically calls the aggregate goal, in the "aggregatedJavadoc" profile, on the parent module, at the prepare-package phase! Then I copy the resulting Javadoc to the build output folder of the module3 module, so it is included in the resulting .jar.
The script that is called by the exec-maven-plugin plugin is custom in my case, but many solutions can be use to programmatically call the target Maven goal: Apache Maven Invoker, for example.
I have jaxws-maven-plugin in parent pom.xml in the pluginManagement tag and I am referring to this plugin in the child pom.
mvn clean install is running fine. But, eclipse is complaining that
"Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:jaxws-maven-plugin:1.12:wsimport (execution: FirstWsdl, phase: generate-sources)".
Could you suggest how to avoid this error in eclipse?
parent pom
<pluginManagement>
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.12</version>
<executions>
<execution>
<id>FirstWsdl</id>
<goals>
<goal>wsimport</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<wsdlLocation>location/file.wsdl</wsdlLocation>
<wsdlFiles>
<wsdlFile>file.wsdl</wsdlFile>
</wsdlFiles>
<packageName>com.xxx.package</packageName>
</configuration>
</execution>
</executions>
<configuration>
<sourceDestDir>${basedir}/generated</sourceDestDir>
<verbose>true</verbose>
<extension>true</extension>
<keep>true</keep>
<vmArgs>
<vmArg .../>
</vmArgs>
</configuration>
</plugin>
...
</plugins>
</pluginManagement>
child pom
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
</plugin>
</plugins>
I looked at this question and reply How to solve "Plugin execution not covered by lifecycle configuration" for Spring Data Maven Builds, but, should I use pluginManagement both in parent and child pom to avoid this error?
If you can't find connectior you can turn off this error in eclipse
because as a documentation says:
To get the Maven execution from within Eclispe to work you don't have to do anything.
so go to Eclipse: Preferences -> Maven -> Error/Warnings and change Error to Warning in option: Plugin execution not converted by lifecycle configuration
This should be:
documented in the wiki page "M2E plugin execution not covered":
Project build lifecycle mapping can be configured in a project's pom.xml, contributed by Eclipse plugins, or defaulted to the commonly used Maven plugins shipped with m2e.
We call these "lifecycle mapping metadata sources".
m2e will create error marker like below for all plugin executions that do not have lifecycle mapping in any of the mapping metadata sources.
illustrated in "How to solve “Plugin execution not covered by lifecycle configuration” for Spring Data Maven Builds" (that you reference).
either by adding the lifecycleMappingMetadata in the parent pom.
or by enclosing the plugins with the <pluginManagement> tag (in both pom).
That thread adds more details to your specific error message:
when taking a look in the Eclipse-UI in the project properties under “Maven” -> “Lifecyle Mapping” (having checked the “Show lifecycle phases” checkbox and disabled “Show ignored executions”), I see the following content.
To my understanding this file shows the mapping between the Eclipse build lifecycle (runtime/incremental) and its bound Maven plugins.
Currently, it does not contain the “jax-ws” plugin respectively its goal “wsimport”.
The problem is that you have the jax-ws plugin declared in the pluginManagement section.
To get a binding to a phase it should be in build/plugins.
Performing a Maven build from CLI wouldn't work either, so I suspect that you're not doing the standard "mvn install"?
To get the Maven execution from within Eclispe to work you don't have to do anything.
But if you want to have incremental/runtime support in the IDE you should get the proper m2e connector. If you look at the pom in the POM editor in Eclipse, the plugin execution should be marked with a red error X. Hover on that and you should get an option to find one ("Discover new m2e connectors").
https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html is the original page which explains it all. Defining it in the parent should be enough for its children.
Go to pom.xml and right click > Add Dependency> enter the Group Id and Artifact Id click ok. This will resolve the "Plugin execution not covered by lifecycle" issue.
Currently we are working on the big maven project that has about 100 modules, some of them have submodules as well.
Some of modules use Maven Build Number plugin. The project is hosted under subversion.
Recently we started to use git locally in our development team.
After cloning subversion repo and trying to build the Project, we received following well known error:
The svn command failed.
Command output:
svn: ‘.’ is not a working copy
Unfortunately in our case it is not an option to create a new profile or just remove plugin definition from POM (this will follow to messing up hundreds of POM files).
I found the following article http://abstractionextraction.wordpress.com/2012/09/27/git-svn-vs-maven-build-number-plugin/ but honestly, it's not something that I would really like to do...
Is there any smart way to disable this plugin. Like command-line parameter?
I think you may skip failure on obtain revision without change project pom.xml - buildnumber-maven-plugin has option revisionOnScmFailure which you may use like:
mvn -Dmaven.buildNumber.revisionOnScmFailure=no-scm package
In that case value no-scm will be used if scm call was unsuccessful. Off course you may change it and provide any other string.
Per the mojo documentation, you could use the revisionOnScmFailure property.
However, it doesn't have a command line option. You'll have to modify those pom.xml files.
See "Defining Parameters Within a Mojo" in the Maven Java Plugin Development Guide
One approach would be to use a property in your pom to specify the execution phase of the build number plugin, as shown below.
<project>
..
<properties>
<buildnumber.plugin.phase>validate</buildnumber.plugin.phase>
..
</properties>
..
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>${buildnumber.plugin.phase}</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
..
</configuration>
</plugin>
</plugins>
..
</project>
Then provide the property on the command line to disable the plugin, as shown in the following example.
mvn install -Dbuildnumber.plugin.phase=none