I have an issue concerning the plugin versions.
When it generates a report with the goal:
mvn versions:display-dependency-updates
It suggest is a lot of libraries that with beta or alpha versions.
org.hibernate:hibernate-validator ......... 4.2.0.Final -> 4.3.0.Beta1
The issue is that event if the goal of this plugin is to show the very latest versions of each dependency, I don't want to use beta/alpha versions for production code. But I don't want to search manually the last stable version neither.
I've tried the 'comparisonMethod' option: numeric, maven, etc. No success whatsoever.
Any ideas for the plugin 'versions' to show the latests available versions of dependencies, but without including beta/alpha?
You can configure the versions plugin like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<rulesUri>someUrl</rulesUri>
</configuration>
</plugin>
someUrl can also be a file URL. The syntax of the rules file is given in http://www.mojohaus.org/versions-maven-plugin/version-rules.html, it may contain something like this:
<ruleset comparisonMethod="maven"
xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<ignoreVersion type="regex">.*-beta.</ignoreVersion>
<ignoreVersion type="regex">.*_ALPHA</ignoreVersion>
</ignoreVersions>
</ruleset>
Related
Small question regarding a SonarQube + Checkstyle warning please.
Currently, in my app, in my pom, I use the following Checkstyle plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.1.2</version>
<configuration>
<outputFile>.out/reports/checkstyle/checkstyle-result.xml</outputFile>
<outputDirectory>target/reports/checkstyle</outputDirectory>
<outputFileFormat>xml</outputFileFormat>
</configuration>
</plugin>
This plugin is doing its job, no worries there.
When I run SonarQube though, I get this warning
Old version of checkstyle detected. Consider updating to >= v8.30
For more information see: https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
I obviously went to read the website, but I am still having hard time understanding.
The Checkstyle plugin I have is the latest known, version 3.1.2, checked on Maven central etc.
In SonarQube, I am running on the latest version, 8.9 LTS, with the latest version of Checkstyle plugin as well.
What am I missing please? Am I using some kind of wrong plugin?
It is a SonarQube plugin named sonar-checkstyle which needs to be installed or upgraded at the SonarQube server instance. The current version is 8.40.
Note: Refer to
https://docs.sonarqube.org/latest/setup/install-plugin/
https://docs.sonarqube.org/latest/instance-administration/plugin-version-matrix/
https://github.com/checkstyle/sonar-checkstyle
https://github.com/checkstyle/sonar-checkstyle/releases
Edit 1
Step 1
Firstly, there is a cache directory at <user_home>/.sonar/cache (for me on the Windows 10 is C:\Users\<myuser>\.sonar\cache), please delete all sub directories under this cache directory with purpose to let the org.sonarsource.scanner.maven:sonar-maven-plugin latest version download it from our SonarQube server instance and ensure that all related plugins are new and fresh after upgrading/installing at the SonarQube server instance. (Do not forget to restart it after finishing upgrading/installing to ensure all new are re-loaded)
Step 2
Secondly, make sure that we do not specify the org.sonarsource.scanner.maven:sonar-maven-plugin in our project pom.xml neither at the parent nor anywhere else with purpose to ensure that during executing, it will be a latest version which matches to our SonarQube server instance version.
Anyhow the formal document (https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-maven/) also mentions about How to Fix Version of Maven Plugin as the following: -
How to Fix Version of Maven Plugin
It is recommended to lock down versions of Maven plugins:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>
<!--Version that matched with our Sonar server instance version -->
</version>
</plugin>
</plugins>
</pluginManagement>
</build>
The latest version is able to be browsed at https://search.maven.org/artifact/org.codehaus.mojo/sonar-maven-plugin or https://search.maven.org/artifact/org.sonarsource.scanner.maven/sonar-maven-plugin The latest is version 3.9.0.2155 (Note: the version ?.y.z is matched with our Sonar server instance version)
Step 3
Last but not least, if our project is a multi-module projects there is a mentioned at the formal document (https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-maven/) as the following: -
In some situations you may want to run the sonar:sonar goal as a
dedicated step. Be sure to use install as first step for multi-module
projects
mvn clean install
mvn sonar:sonar ...
Then there will be 2 steps here, mvn clean install first so that it is completed and then mvn sonar:sonar ... later on.
Edit 2
The maven-checkstyle-plugin is also able to specify the checkstyle version as mentioned at https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html with the significant sentence as
Maven Checkstyle plugin comes with a default Checkstyle version: for
maven-checkstyle-plugin 3.1.2, Checkstyle 8.29 is used by default.
Then the configuration for the maven-checkstyle-plugin will be like the following: -
<project>
...
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.1.2</version>
<dependencies>
<dependency>
<groupId>com.puppycrawl.tools</groupId>
<artifactId>checkstyle</artifactId>
<version>...choose your version...</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
<build>
...
</project>
The latest version is able to be browsed at https://search.maven.org/artifact/com.puppycrawl.tools/checkstyle The latest is version 8.42.
I'm trying to use the maven versions plugin to update my pom to the next snapshot version. eg. 0.0.1 should change to 0.0.2-SNAPSHOT.
From my reading of http://www.mojohaus.org/versions-maven-plugin/set-mojo.html I would expect mvn versions:set -DnextSnapshot=true to do this, but in reality it just prompts me for a new version with a default of the current version (0.0.1). Am I missing something here? I want to do this update as a part of a script so don't want any manual intervention.
I'm using v2.5 of the versions plugins. That link above says that nextSnapshot is available from 2.10 but 2.5 seems to be the latest I can find.
I also faced this issue. I got to know that my Maven project was picking up older version (2.3) of Versions Plugin. This no longer seems to be a problem in latest version (2.7) of the plugin.
I added following in pom.xml of my project to force my project use 2.7 version of Maven Versions plugin.
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.7</version>
</plugin>
</plugins>
</pluginManagement>
Otherwise, you can mention latest version of Versions plugin to choose in command line :- mvn org.codehaus.mojo:versions-maven-plugin:2.7:set -DnextSnapshot=true
I want to use svn revision number of pom file as its version.
In pom.xml, if we use buildnumber-maven-plugin, we need to define scm repository url, so that it can check to repository and use buildnumber.
But i want to ask that when we have checkedout code to our system, isn't there any way to get buildnumber without using scm urls. As revision number is stored as subversion in property of each file. we can see it if we right click on file and go to properties.
I want to use buildnumber in version tag of pom and other module's buildnumber in their vaersion tag in dependencies to them.
So if i can store all subversion numbers initially, infact earlier than resolving dependencies, then these subversions can be placed in version of module in dependency and also in version of each pom file.
Problem is that dependencies are resolved before plugin reads version number ( this is what i think), so it cannot resolve expression.
I tried it using properties-maven-plugin to write pom's version number in a file and then read it in other module's pom which is dependent on it. But dependencies are to be resolved before execution of any plugin is started.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>pre-clean-config</id>
<phase>validate</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${project.basedir}/../app.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
So, it is not working.
Starting with Maven 3.2.1 you can define a property ${revision} which you can use in your versions like this:
<project...>
<groupId>..</groupId>
<artifactId>...</artifactId>
<version>1.0-${revision}</version>
...
The result of this you need to give a property while calling Maven like this:
mvn -Drevision=123456 clean package
This will also work in dependencies etc. Currently one drawback is that you always creating a release from maven's point of view.
I've been tasked with reducing the download size of one of our webstart apps. I've figured that a decent portion of the download is from all a largish library of jar files, and since we rarely update many of them, it seems the download will be reduced significantly using the JNLP Version Download Protocol. This should stop the continual re-download of the same jars when a new version of the app is released.
Now, the project is build with maven. Part of the process is automatically generating a JNLP file from a velocity template. The resources section of the JNLP file is populated by a $dependencies variable assumedly passed in by maven and looks something like this:
<jar href="lib/mainjar-0.1.40-SNAPSHOT.jar" main="true"/>
<jar href="lib/somejar-1.1.jar"/>
<jar href="lib/someotherjar-1.0.jar"/>
<jar href="lib/anotherjar-1.6.0.jar"/>
etc...
It seems to me that maven is using its standard naming convention and constructing the jar names from the artifactId and version tags out of the project pom files.
How can I get it to use the JNLP naming convention instead?
I can change the velocity template to cut the $dependencies variable up and re-combine it with the JNLP convention - but that's only halfway what I need since the actual jar names need to be changed too.
The version download protocol article is about speeding up the check that resources are up to date. Although it may be useful as well, it is not the part that prevents re-downloading of the same files.
Webstart-maven-plugin can take care of versioning of the jars for you and they declare they use the version protocol as well. See http://www.mojohaus.org/webstart/webstart-maven-plugin/jnlp-mojo.html#outputJarVersions
My personal experience differs from what the docs say. It adds the version attribute for jars in the resulting jnlp and does not set the jnlp.versionEnabled property, which seems to be required for the version download protocol. Either way JWS works as I would expect - files are not re-downloaded when their version does not change.
Plugin setup:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webstart-maven-plugin</artifactId>
<version>1.0-beta-6</version>
<dependencies>
<!--This dependency definition resolves class loading issue on Java 8 -->
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>keytool-api-1.7</artifactId>
<version>1.4</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>jnlp-download-servlet</goal>
</goals>
</execution>
</executions>
<configuration>
<outputDirectoryName>/</outputDirectoryName>
<libPath/>
<sign>
<keystore>${basedir}/foo-key-store.jks</keystore>
<storepass>password</storepass>
<alias>foo-self-signed</alias>
<verify>true</verify>
</sign>
<unsign>true</unsign>
<jnlpFiles>
<jnlpFile>
<inputTemplate>template.vm</inputTemplate>
<outputFilename>foo.jnlp</outputFilename>
<jarResources>
<jarResource>
<groupId>foo.bar</groupId>
<artifactId>foo</artifactId>
<version>${project.version}</version>
<mainClass>foo.bar.Foo</mainClass>
<outputJarVersion>false</outputJarVersion>
</jarResource>
</jarResources>
</jnlpFile>
</jnlpFiles>
<gzip>true</gzip>
</configuration>
</plugin>
Excerpt from the generated foo.jnlp showing the version attribute of a dependency:
<jar href="commons-collections.jar" version="3.2.1"/>
And the file it references is named:
commons-collections-3.2.1.jar
We use Maven through a local Nexus repository. Unfortunately, when querying for new versions, we get several false positives:
commons-collections:commons-collections ............ 3.2.1 -> 20040616
org.hibernate:hibernate-entitymanager ..... 4.1.9.Final -> 4.3.0.Beta1
The first is a version that is ancient but with an incorrect naming scheme. The second is actually only a beta version (we don’t usually get these, but some seem to slip through). Now the question is: How can these versions, which are not really on our repository but come from one of the repositories our Nexus refers to, be excluded?
I have tried routing, but either I got it wrong or it cannot block specific versions, only the complete artifacts with all its versions. I have seen procurement in the documentation, but it seems very complicated and I did not dare trying.
You may configure the versions-maven-plugin in your project's POM (or a corporate parent somewhere) to use a rules file telling the plugin which versions to ignore.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<!-- some location that makes sense for your company/project -->
<rulesUri>http://host.company.com/maven-config/maven-version2-rules.xml</rulesUri>
</configuration>
</plugin>
An example rules file looks like the below. Mine ignores the "99.0-does-not-exist" version of the commons-logging plugin.
<ruleset xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0
http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<rules>
<rule groupId="commons-logging" artifactId="commons-logging">
<ignoreVersions>
<ignoreVersion>99.0-does-not-exist</ignoreVersion>
</ignoreVersions>
</rule>
</rules>
</ruleset>
You may add configuration to ignore other versions globally, not per-artifact as I did here, and regular expressions may be used as well. More information is available in the plugin documentation.