How to show plugin versions - java

I want to know the version of plugin installed. Which command can do it?

mvn -Dplugin=<groupId>:<artifactId> help:describe
detailed description of the plugin - including the version

If you would to know which version of plugins (incl. plugins provided through maven master pom) your build use, try:
mvn help:effective-pom

I don't know what you mean by 'version of plugin installed' but the Maven help plugin enables you to get the desciption of a plugin by giving the groupId and artifactId,
mvn -Dplugin=<groupId>:<artifactId> help:describe
You will get a detailed description of the plugin - including the version (although I must admit that I don't know the strategy of version number resolving).
Example for the maven-dependency-plugin
mvn -Dplugin=org.apache.maven.plugins:maven-dependency-plugin help:describe
Output:
Name: Maven Dependency Plugin
Description: Provides utility goals to work with dependencies like copying,
unpacking, analyzing, resolving and many more.
Group Id: org.apache.maven.plugins
Artifact Id: maven-dependency-plugin
Version: 2.2
Goal Prefix: dependency
This plugin has 21 goals:
dependency:analyze
Description: Analyzes the dependencies of this project and determines which
are: used and declared; used and undeclared; unused and declared. This goal
is intended to be used standalone, thus it always executes the test-compile
phase - use the dependency:analyze-only goal instead when participating in
the build lifecycle.
dependency:analyze-dep-mgt
Description: This mojo looks at the dependencies after final resolution and
looks for mismatches in your dependencyManagement section. In versions of
maven prior to 2.0.6, it was possible to inherit versions that didn't match
your dependencyManagement. See MNG-1577 for more info. This mojo is also
useful for just detecting projects that override the dependencyManagement
directly. Set ignoreDirect to false to detect these otherwise normal
conditions.
dependency:analyze-duplicate
Description: Analyzes the <dependencies/> and <dependencyManagement/> tags
in the pom.xml and determines the duplicate declared dependencies.
... and much more

Add this to your pom.xml file and you will get the result on mvn clean install:
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
<goal>display-plugin-updates</goal>
<goal>display-property-updates</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
If you just want to do it once:
mvn versions:display-plugin-updates

You can add an "-X" parameter when maven is packaged(mvn clean compile * -X), and then search for "artifactId" to see the exact version number.

Related

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.)

Why does maven-enforcer-plugin detect maven 3.2.5 when it's run with 3.1.1 on travis-ci.org?

I have a project document-scanner-aggregator which runs fine locally when run with Maven 3.1.1, i.e. ~/apache-maven-3.1.1/bin/mvn clean install, but doesn't on travis-ci.org where it detects Maven 3.2.5 which suspiciously is the version provided by travis-ci.org. However it's not supposed to do that, because the Maven version which runs the build is supposed to be enforced, right?
The failure is
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireMavenVersion failed with message:
Detected Maven Version: 3.2.5 is not in the allowed range (,3.2).
...
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce (enforce-versions) on project javaocr-parent: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed. -> [Help 1]
and the configuration is
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>enforce-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<!--different rules for different issues-->
<!--3.3.x causes `java.lang.NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State` which is caused by certain maven versions, see https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound for details-->
<version>(,3.3)</version>
<!--3.2.x causes `No implementation for org.eclipse.aether.connector.wagon.WagonConfigurator was bound.`-->
<version>(,3.2)</version>
</requireMavenVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
in javaocr.
The .travis.yml is
language: java
install:
- wget http://mirrors.ae-online.de/apache/maven/maven-3/3.1.1/binaries/apache-maven-3.1.1-bin.tar.gz && tar xf apache-maven-3.1.1-bin.tar.gz
- apache-maven-3.1.1/bin/mvn clean install
You're misunderstanding the role of the Enforcer Plugin:
The Enforcer plugin provides goals to control certain environmental constraints such as Maven version, JDK version and OS family along with many more standard rules and user created rules.
Its goal is not to do magic so that the configured rules are verified, but it is to fail the build when one of the rules is not verified. Put another way, it checks the list of configured rules, so that the build cannot continue if one of those isn't verified. The reason is that if one of the pre-requisite for the build is not met, it is better to fail as early as possible.
In your case, the requireMavenVersion rule enforces that the build is done with a Maven version strictly lower than 3.2. It will not spawn a new Maven instance if you're running the build with a Maven 3.2.5 so that the rule is verified; which version should it use, and where would it get it? Instead, it detects that the build is done with a Maven version that is disallowed, and fails accordingly. Since the Travis build is configured to use Maven 3.2.5, it is expected to fail, and you need to install a Maven version lower than 3.2 for your Travis build.
To use a different Maven version, like 3.1.1, on Travis CI, you can have the following in .travis.yml:
before_install:
- wget http://mirrors.ae-online.de/apache/maven/maven-3/3.1.1/binaries/apache-maven-3.1.1-bin.tar.gz
- tar xf apache-maven-3.1.1-bin.tar.gz
- export M2_HOME=$PWD/apache-maven-3.1.1
- export PATH=$M2_HOME/bin:$PATH
install: /bin/true
script: mvn clean install
As a side-note, your current configuration of
<requireMavenVersion>
<version>(,3.3)</version>
<version>(,3.2)</version>
</requireMavenVersion>
is completely equivalent to
<requireMavenVersion>
<version>(,3.2)</version>
</requireMavenVersion>
The range (,3.2) means that it matches version strictly lower than 3.2. Therefore, requiring that it is also strictly lower than 3.3 is redundant (since 3.2 is before 3.3).

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

How does Maven understand release:prepare command?

I'm trying to create a plugin which would download and install jars from Maven central as system tools. So I want my line to be like
mvn install-plugin:install org.chaschev:cap4j:1.0
similar to Ruby's
gem install capistrano
This plugin would gather all the needed information about the shortcuts to create from the JAR. I.e. this jar would contain a class implementing an installation interface.
How does Maven understand that in order to execute a command like release:prepare it requires to download the release plugin and to run it? Any better/other way to do this?
Do you mean how the relation between plugin/goal in the comamnd line and plugin implementation is defined? Then the answer is plugin.xml. See plugin.xml for release plugin, e.g. maven-release-plugin-2.0.jar:
<goalPrefix>release</goalPrefix>
...
<mojos>
<mojo>
<goal>help</goal>
...
<mojo>
<goal>prepare</goal>
...
Or do you mean, how Maven discovers which plugins are available? Then the answer is:
There are two default groups where plugins are searched, org.apache.maven.plugins and org.codehaus.mojo
For your own plugin you may want to use name ${prefix}-maven-plugin, e.g. cap4j-maven-plugin
You can keep your name cap4j, but then put the plugin description to your POM, under <plugins>
If you want your build to work at other machines, they should point <pluginRepositories> in POM or in settings.xml to your plugin repository
It is not good to use default Maven groups for your own project.
Instead, define your own group for your plugin, like this:
<pluginGroups>
<pluginGroup>org.chaschev</pluginGroup>
</pluginGroups>
And rename your plugin from cap4j to cap4j-maven-plugin. Then Maven will discover your plugin without further cahnges in POM.
Alternative, without <pluginGroups>, just put following to your POM:
<plugins>
<plugin>
<groupId>org.chaschev</groupId>
<artifactId>cap4j</artifactId>
<version>...</version>
<configuration>
...
</configuration>
</plugin>
...
</plugins>

maven surefire reporting plugin configuration

I have a multi-module maven project. The parent pom.xml is simply a way to reference common information for the 4 subprojects. I have quite a few JUnit tests that run and I also have the Parent Project set up for Project WebSite using the maven-info-reports-plugin.
I have the maven-surefire-report-plugin configured in the parent and it generates the target/site/surefire-report.html file in each of the subprojects with the correct information.
My problem is when I run my project website via site:run I do not see any of the surefire-report.html files in the Project website. The one that shows is in the target directory of the parent and it has no unit tests defined.
Is there a way I can configure maven-surefire-report-plugin or maven-info-reports-plugin to aggregate the subprojects generated surefire reports?
To elaborate on Seph's answer. You can set many of the Maven reports to aggregate results. To do this with the surefire-report plugin you'd do something like this:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.4.2</version>
<configuration>
<aggregate>true</aggregate>
<!--also set this to link to generated source reports-->
<linkXRef>true</linkXRef>
</configuration>
</plugin>
</plugins>
</reporting>
Note the additional linkXRef property, this allows you to add cross-references to the generated html version of the source produced by the jxr plugin. The jxr plugin can also be set to aggregate, so the two combined allow you to browse your entire project structure.
As far as I know, the maven-info-reports-plugin doesn't do aggregation.
You can add
<aggregate>true</aggregate>
to the surefire plugin in the parent pom.xml.
For command line
mvn surefire-report:report -Daggregate=true
It could be -
mvn clean test -fn surefire-report:report -Daggregate=true
OR
mvn clean install -fn surefire-report:report -Daggregate=true
Note :
fn -> NEVER fail the build, regardless of project result
To add in pom
<aggregate>true</aggregate>

Categories