We Keep Coding

Configure maven plugin version without changing pom.xml manually

Problem Description
I'm working with a collection of old projects from defects4j. My problem now is that since I want to combine those projects with a newer maven plugin, a regression test tool, there are some issue with the maven surefire plugin version.
In the pom.xml that come along with the projects, there are no specifications of surefire version:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>plain</id>
<configuration>
<includes>
<include>**/*Test.java</include>
</includes>
<runOrder>random</runOrder>
</configuration>
</execution>
</executions>
</plugin>
However, the regression tool (made into a maven plugin), require surefire version of 2.14 and above. So I get error like this:
[ERROR] Failed to execute goal edu.illinois:starts-maven-plugin:1.4-SNAPSHOT:select (default-cli) on project commons-lang: Unsupported Surefire version: 2.12.4. Use version 2.13 and above
Efforts Done
I checked several stackoverflow posts, and they talked about the effective pom. When I run mvn help:effective-pom, I can see that the version of surefire used is
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.4</version>
Question
Since the project collection in defects4j does not specify surefire version in their pom.xml, is there a way to specify the surefire version used to 2.14 or above from command line? I want to prevent from manually editing the pom every time.
Update
by running mvn dependency:resolve-plugins, i get
Plugin Resolved: maven-surefire-plugin-2.12.4.jar
So it seems to me that somehow maven use 2.12.4 as a default. The reason maybe that I used this version previously. How do I fix this?
Without modifying the pom manually?
Any advice will be welcomed!
Update:
Problem solved by editing maven's super pom.

Maven takes the newest version from the repository if there was no version fixed in your POM, parent POM or the super POM (from which every Maven project inherits).
It is best practise to fix a version "manually" in the POM. The best place for this is a parent POM from which the projects inherit (this means, only one place to change).
You cannot just supply a version from command line. Unless you do some tricks like putting <version>${surefire.version}</version> into the plugin definition and set this property from command line.

I'm 4+ years removed from working with poms so don't remember everything, but consider a couple of things.
First, since the pom you show isn't specifying the version of surefire to use I don't think that the 2.12.4 version can be coming from that directly. Try getting a dependency tree to see where things are coming from. Try How can you display the Maven dependency tree for the *plugins* in your project? for that and a few other suggestions.
Second, I think I recall that in your own pom you should be able to specify the version of plugin to associate with a dependency that doesn't specify one. You'll have to research that option yourself.
I think your best bet is the dependency tree to find what's using what and where things are coming from. If you get the tree and still can't figure out what to do try adding the tree output to your question. (You can edit out parts that are proprietary, or clearly unrelated.)

How do I create an Eclipse plugin release using Maven and Tycho?

I am building an Eclipse project that consists of a number of plug-ins that are packed together. I have create POM files for each component and a main POM for the project. Something like this:
projectDir\releng\pom.xml <-- Parent project
projectDir\proj1\pom.xml <-- Child project 1
projectDir\proj2\pom.xml <-- Child project 2
My build currently works by calling the parent POM which builds everything. Until now I have been building using 0.0.1-SNAPSHOT as the version of the parent POM, and in each Eclipse plug-in I have 0.0.1.qualifier as the version in the MANIFEST.MF file.
I now want to promote my latest version to 0.1.0. From my understanding, this means that I have to go over ALL of my POM files AND MANIFEST.MF files and upgrade the version in both of them (since while the version is defined in the parent POM, it is referenced in all child POM:s).
Is this the correct way to do this or is there a way to automate the whole process and not make mistakes?
P.S. There is the Maven Release plugin but this won't work with Eclipse.

For the version update step of a relase process, there is the tycho-versions-plugin which knows how to consistently update the POMs and manifests.
Just go to the root of your parent/aggregator module and call
mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion="0.1.0"
This will update the version of the parent project and of all child projects with the same/equivalent version as the parent project. In your case, these are all projects because the Eclipse versions 0.0.1.qualifier is considerered equivalent to 0.0.1-SNAPSHOT in Tycho.
For the remaining steps of the release process (tagging, building, pushing tags, etc.) just call the appropriate SCM or Maven commands, e.g. from a script. I haven't tried to use the maven-release-plugin for this (and apparently no-one else has).

Please have a look here: Unleash Maven Plugin - Tycho Releases
The Unleash Maven Plugin is implemented as an alternative to the Maven Release Plugin and has a Tycho feature which should do exactly what you need. Furhtermore it is much more flexible, failure tolerant and has an integrated rollback feature.
I will publish some blog posts soon to promote and explain this plugin.

just some hints on how we implemented it.
It can be done with an extra plugin that does transformation of versions in MANIFEST.MF and *.product files. This plugin needs to be a lifecycle participant. #Component(role = AbstractMavenLifecycleParticipant.class) the reason for this is that is must transform and commit before the release plugin starts to look for modifications. Then it must also to transformation back after the release.
The mojo executor plugin saves a good deal of work since it can call the replacer, buildhelper and scm plugin from inside your plugin.
Another important gotcha is that you need to disable to hard coded clean invocation that tycho does by confguring the release plugin to configure the clean plugin to skip execution.
Hope this helps.

There is a new feature in tycho-1.1.0 (unreleased at the time of this post) that should support what you're trying to do.
If you've configured your pom correctly for standard maven-release + added the dep to tycho 1.1.0, you can customize your build as follows [1]:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<preparationGoals>org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata org.apache.maven.plugins:maven-scm-plugin:1.9.5:add org.apache.maven.plugins:maven-scm-plugin:1.9.5:checkin</preparationGoals>
<completionGoals>org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata org.apache.maven.plugins:maven-scm-plugin:1.9.5:add org.apache.maven.plugins:maven-scm-plugin:1.9.5:checkin</completionGoals>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-plugin</artifactId>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>add</goal>
<goal>checkin</goal>
</goals>
<configuration>
<includes>**/META-INF/MANIFEST.MF, **/feature.xml, **/*.product</includes>
<excludes>**/target/**</excludes>
<message>Changing the Eclipse files versions</message>
</configuration>
</execution>
</executions>
</plugin>
[1] This is taken directly from a tutorial that describes this new feature:
https://wiki.eclipse.org/Tycho/Release_Workflow

PMD multiple rulesets pass build but single ruleset fails build

I am using PMD maven plugin for my project and I am seeing very strange behavior in it. The following pom.xml configuration fails the build with violations in basic.xml -
<configuration>
<rulesets>
<ruleset>${project.basedir}\ruleset\basic.xml</ruleset>
<!-- ruleset>${project.basedir}\ruleset\braces.xml</ruleset>
<ruleset>${project.basedir}\ruleset\design.xml</ruleset>
<ruleset>${project.basedir}\ruleset\controversial.xml</ruleset>
<ruleset>${project.basedir}\ruleset\coupling.xml</ruleset>
<ruleset>${project.basedir}\ruleset\clone.xml</ruleset>
<ruleset>${project.basedir}\ruleset\comments.xml</ruleset-->
</rulesets>
</configuration>
But the below one passes the build smoothly -
<configuration>
<rulesets>
<ruleset>${project.basedir}\ruleset\basic.xml</ruleset>
<ruleset>${project.basedir}\ruleset\braces.xml</ruleset>
<ruleset>${project.basedir}\ruleset\design.xml</ruleset>
<ruleset>${project.basedir}\ruleset\controversial.xml</ruleset>
<ruleset>${project.basedir}\ruleset\coupling.xml</ruleset>
<ruleset>${project.basedir}\ruleset\clone.xml</ruleset>
<ruleset>${project.basedir}\ruleset\comments.xml</ruleset>
</rulesets>
</configuration>
The build should have failed in the second scenario also. As per what I have noticed, if the last rule (in above example comments.xml) does not have any code violation then the build will not break even if any of the rulesets above it (basic.xml, braces.xml, etc.) have code violations. I am unable to understand the reason behind this behavior. Can someone help me out with this?

I found the issue. There was an issue with Maven Plugin version 3.3 . Now I am using version 3.1 and the exact same code is working as expected.

Maven Plugin for project semantic versioning

I'm looking for a maven plugin that will help me manage version names and codes of every build that is made on our CI environment. Something that will be able to attach a prefix to the main version code or even update it (not changing the pom.xml). For example:
project version: 2.0.1
git/svn revision: 2342334
jar output: name-2.0.1-2342334.jar
maven repo: ../path/to/local/maven/repo/<package path>/2.0.1-2342334/
The main requirements to this plugin are:
Must be in Maven Repository (which means that NO additional setting required to add this plugin in my pom.xml and run maven)
Must not edit the pom, each time it's applied
A configuration file, would be great, so I could manage the versioning process
Must be able to edit the output file metadata (so the version will be applied as if it was written in the pom.xml file in the first place)
So far I found only maven-buildmetadata-pluging but unfortunately it's not in Maven Repo, so I'm stuck. Any help would be great.

Hosting your own maven repository is very easy, using either Nexus or Artifactory. You can also use the Artifactory cloud version (I'm not affiliated with them...) so it may solve your problem. BTW - a simple server with Apache does the trick as well, but with more work..,
Regarding the plugins: If you deploy snapshot applications then each gets its own version based on timestamp.
For releases another option is to run an svn info and put the result (or part of it) into the generated artifact. The information can then be accessed by the code.

If you change the version of your artifact the pom has to reflect the change, cause otherwise it's not reproducible.
If you change something in your build process (like added versions, whatever) it has to be reflected in the pom file. Otherwise you can not reproduce the build process with the same result.
You have written not to change the pom file but maintaining a separate file. So the questions is: Why not using the pom file itself, cause it's intended exactly for that purpose.
Furthermore all informations which you mentioned by the maven-buildmetadata-plugin can be achived by using existing maven plugins (like build-helper-maven-plugin, buildnumber-maven-plugin).
The SCM information can be used by using the buildnumber-maven-plugin which provides information like SCM revision number (SVN or GIT hash).
An on the other hand if you don't like to change your pom file manually you can use either the versions-maven-plugin or the maven-release-plugin which automatically can change informations in your pom file and handle all these things automatically.
To maintain metadata in your producted artifacts you can configure all plugins (like ear, war, jar) etc. more or less like this where the buildNumber is comming from buildnumber-maven-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>${maven-jar-plugin.version}</version>
<configuration>
<archive>
<addMavenDescriptor>true</addMavenDescriptor>
<index>true</index>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<artifactId>${project.artifactId}</artifactId>
<groupId>${project.groupId}</groupId>
<version>${project.version}</version>
<buildNumber>${buildNumber}</buildNumber>
</manifestEntries>
</archive>
</configuration>
</plugin>
And of course if you really like to use Maven you should have to use an repository manager as already mentioned like Artifactory or Nexus which make life easier.

I just would like to add (although the question is 5 years old and already has an accepted answer) that the Buildmetadata Maven Plugin was not available on the Maven Repo at first, but it is now (since late 2013). People who would like to give it a try find the artifact at the following locations :
com.redhat.rcm.maven.plugin:buildmetadata-maven-plugin
de.smartics.maven.plugin:buildmetadata-maven-plugin
Please note that the name has changed from maven-buildmetadata-plugin to buildmetadata-maven-plugin due to naming conventions.
I'm one of the "original" authors of this plugin at smartics. If you would like to use it, you probably would like to use the fork provided by Red Hat. To my knowledge the two versions do not differ very much and they have not been synced since there is just so much other stuff to do and the plugin seems to be feature stable. ;-)
The source code for both versions is also available on GitHub:
release-engineering/buildmetadata-maven-plugin
smartics/buildmetadata-maven-plugin

As already stated, you have to change the version in the pom. One way of doing that, in combination with the release plugin is:
mvn \
se.bjurr.gitchangelog:git-changelog-maven-plugin:VERSION_HERE:semantic-version \
release:prepare release:perform
Using Git Changelog Maven Plugin

m2e still gives an error saying "Plugin execution not covered by lifecycle configuration" even with explicit bindings in custom plugin

I'm building a plugin to do some code generation.
I've followed the steps here for how to create a plugin:
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
Plugin Source:
/**
* #goal helloworld
* #phase generate-sources
*/
public class SampleMojo extends AbstractMojo
{
#Override
public void execute() throws MojoExecutionException, MojoFailureException
{
getLog().info("Hello, world.");
}
}
Usage:
<plugins>
<plugin>
<groupId>com.sample</groupId>
<artifactId>sample-maven-plugin</artifactId>
<version>0.0.1</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>helloworld</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
The plugin works fine on its own, but in Eclipse, I keep getting the "not covered by lifecycle" error.
I read through "How to solve “Plugin execution not covered by lifecycle configuration” for Spring Data Maven Builds" and I assumed that if I created my own plugin and set the #phase and #goal annotations it would get rid of that error. I really don't want to put in the "lifecycleMappingMetadata" node in the pom.
Anyone have any advice on this? Is there something special that I need to write for m2e to get that error to go away?

K. Claszen's answer is correct, but I'd like to fill out some extra details.
A. Why is m2e like this?
The point of this behaviour is to prevent m2e from consuming too many resources with incremental (& potentially never-ending) changes.
B. m2e version 1.1 is not a 'release' yet
Currently m2e 1.1 is still a 'milestone'.
Users would need to install/upgrade-to it with this update site:
http://download.eclipse.org/technology/m2e/milestones/1.1
(I also had to uninstall an 'm2e SCM connector' in order to upgrade it)
Right now, this is potentially more hassle for your users than inserting the 'Quick Fix' snippet in their pom.xml files. But, in the long-term it's good to use it.
C. Overview of making your maven plugin m2e-1.1-compatible
As described by K. Claszen, most of the info is here: M2E compatible maven plugins.
Some key points:
Execution information is defined in a file - src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml - see M2E compatible maven plugins for format.
If you have enabled 'incremental execution', your Mojo will need to communicate properly with the Maven API:
Specify a dependency to org.codehaus.plexus/plexus-build-api/0.0.1 (current at time of writing)
Use org.codehaus.plexus.build.incremental.BuildContext, to:
Check whether relevant resources have changed
Notify Maven about relevant write operations executed by the plugin, so that it knows to compile sources, etc.
D. Alternatives
If 1.1 isn't a realistic option for your users, you could:
Create an 'M2E Extension Eclipse plugin' (!!), aka an 'M2E Connector', and contribute it to the marketplace. Good luck with that.
Inform your plugin users to select the M2E 'Quick Fix', and then manually change the <ignore /> line to <execute />. There are other SO questions/answers which cover this.

I think the M2E compatible maven plugins site will give you the information you need. Notice that this works first since m2e version 1.1.