Develop Reference

Versions Maven Plugin rules that are inheritable

When running mvn versions:display-dependency-updates for the Version Maven Plugin I see lots of things like this:
[INFO] org.slf4j:slf4j-api ........................... 1.7.36 -> 2.0.0-alpha7
But just because I'm not using the alpha version of a later version doesn't mean I'm not using the latest available release version. Another Stack Overflow answer indicated that I can set up a rules.xml file to ignore versions like *.-alpha*, putting something like this in my POM:
<configuration>
<rulesUri>file:///${project.basedir}/rules.xml</rulesUri>
</configuration>
My question: is this rules.xml file inheritable? If I put it in a separate project in a parent POM of <packaging>pom</packaging>, published to Maven Central, will the child POMs pick it up? Or will the child projects look for a rules.xml file in the child project directory?
I want to configure the versions-maven-plugin in the parent POM (as I do already) and run mvn versions:display-dependency-updates on any child POM or descendant POM. How can I set up the ignore rules in the parent POM so that these version ignore rules will be picked up when I check for dependency updates in a child POM? (Is there no way to include the rule within the POM itself?)

Or will the child projects look for a rules.xml file in the child project directory?
Yes, if you define the rules.xml file via ${project.basedir} it will resolve to the current local base directory of the child project. I've verified this with a simple parent-child pom setup. So that will not work, unless you duplicate the rules file in every project.
If you wish to include the plugin configuration and ruleset in the parent pom without duplicating the rules file, you have two options:
If you have your ruleset xml file hosted at, for example, http://www.mycompany.com/maven-version-rules.xml then the following configuration in your corporate pom would ensure that all projects use this rule set.
<configuration>
<rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
</configuration>
or
You can provide your ruleset xml file also within a jar, if you want to distribute your ruleset xml as Maven artifact. Therefore you have to declare the containing jar as direct dependency of the versions-maven-plugin and to use classpath as protocol.
<configuration>
<rulesUri>classpath:///package/foo/bar/rules.xml</rulesUri>
</configuration>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>version-rules</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
Source:
https://www.mojohaus.org/versions-maven-plugin/version-rules.html
The configuration in the pom only has rudimentary includes and excludes filters. Those will allow you to exclude any dependency as a whole, but not specific update versions. As far as i can tell from the available documentation there is no way to define version rules in any other way.
See
https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
Update 09-2022
In the github ticket we found in the comments we can see the following update:
It looks like a feature like this has recently been implemented by #369. Please see #318 where it's possible to provide inclusion and exclusion filters for determining which dependency patterns will be considered. Thanks to that, you can rule out patterns such as .*-beta. or .*_ALPHA, albeit not using regexp, but simple asterisk wildcards.
This will land in today's release (2.12.0).
This will add the following features:
Version 2.12.0 will introduce new arguments: dependencyIncluded, dependencyExcludes, dependencyManagementIncludes, dependencyManagementExcludes.
With the following example configuration in pom.xml given:
<profile>
<id>display-dependency-updates</id>
<build>
<plugins>
<plugin>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<dependencyIncludes>org.apache.maven.*:doxia*</dependencyIncludes>
<dependencyManagementIncludes>com.puppy*:*</dependencyManagementIncludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This will also be implemented for filtering plugin and pluginManagement, but that will probably be added in a later release:
So, I've just added the missing plugin- and plugin management filtering which works likewise. I really doubt it will land into today's release though.

Pasting my answer here from Github, because I think it might benefit others.
Provided you have a directory called rules-test in your project containing the rules template file:
<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
https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<ignoreVersion type="regex">${ignoredVersions}</ignoreVersion>
</ignoreVersions>
</ruleset>
Then, in your main project, create the following profile:
<profile>
<id>rules-test</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>rules-test</directory>
<filtering>true</filtering>
</resource>
</resources>
<outputDirectory>${project.basedir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.12.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<rulesUri>file://${project.basedir}/compiled-rules.xml</rulesUri>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
If you then execute the following Maven target:
mvn -P rules-test "-DignoredVersions=.*-(M\d*|.*-SNAPSHOT)" clean validate
then you will get a dependencies report using the filter in the -DignoredVersions argument (filtering out both *-M* and *-SNAPSHOT).
And if you put your ignoredVerions property in your project instead of passing it as a -D argument, then it will be inheritable!

Maven Axis Generated classes are not usable in project

Got some issues with axis generation from wsdl
Once generated, classes are not visible eclipse /target folder (I can see them in a terminal...)
I cannot include them and use them.
I guess I'm missing something here, axis and soap are such a pain...
The project jar contains the generated classes, I can add it to build path manually and that works.
If I'm including the maven module in another module, maven complains "
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-wsdl2code-maven-plugin</artifactId>
<version>1.5.4</version>
<executions>
<execution>
<id>generate 1</id>
<goals>
<goal>wsdl2code</goal>
</goals>
<configuration>
<packageName>com.test</packageName>
<wsdlFile>path.to.wsdl</wsdlFile>
</configuration>
</execution>
</executions>
</plugin>

The issue here is that axis2-wsdl2code-maven-plugin is putting the JAR in a non standard place - this is why maven complains when you try in add it as a dependency.
Can you see the JAR being installed into your local maven repo?

build-helper-maven-plugin adding additional source

I am trying to add an additional source folder to my current maven project by using build-helper-maven plugin.
This source folder contains some common classes, like utility classes.
For that, here is my relevant pom.xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.9.1</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>C:/Users/CommonIncludes/src</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
Eclipse is showing the following error :
Build path entry is missing.
Project->Right Click->Java build path->Source->
Project/Users/CommonIncludes/src(missing)
Here the additional source location : "C:/Users/CommonIncludes/src" is outside of the workspace of the current project. But eclipse always treating this as a location from current project.
I am using Eclipse 4.3 and m2e.
How can I overcome this error through MAVEN, so that Eclipse can identify the linked source from correct location.? Or is there any alternate way to do this using MAVEN?
Any help will be greatly appreciated. Thanks in advance.

Found it in an alternate way..works great.!
Steps include
1. Removed build-helper-maven-plugin from pom .
2. Created another maven project and added the common classes in it. Added maven-source-plugin in this pom to generate sources.
3. To the same pom, added maven-dependency-plugin to copy this generated sources to the desired location (My project's src/main/java).
4. Run a maven build for common classes project.
Now the common code in my project. Thanks.

I had a lot of inconsistent trouble with this plugin.
by far the simplest workaround in my case was simply to apply the addition via the standard 'resources' options.
hope this helps someone.
<build>
<resources>
...
<resource>
<directory>${project.build.directory}/generated-sources</directory>
<targetPath>${project.build.outputDirectory}</targetPath>
</resource>
</build>

maven copy a particular dependency jar to a specific directory in the .war file

I am trying out a Simple Java Web Start project based on the Oracle Tutorial. I am using maven to package it as a webapp and deploy it to application server. The full source code is available here
https://github.com/KiranMohan/dynamic-tree-javaws-sample-project
The maven project structure is like
parent
|--lib
|--webapp
The webapp module is a maven war module. It is required to package lib.jar at the root of webapp.war. NOT under WEB-INF/lib.
How to achieve this in maven?

I found that the right way to do this is to use the maven-dependency-plugin.
Since "lib.jar" is not used in the compile phase of "webapp" module, it is only a package time dependency. Using maven-dependency-plugin, I can copy lib.jar to any required directory during the prepare-package phase. The maven-war package would then include the lib.jar in the .war package.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy</id>
<phase>prepare-package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>[ group id ]</groupId>
<artifactId>[artifact id]</artifactId>
<version>[ version ]</version>
<outputDirectory>${project.build.directory}/${project.artifactId}</outputDirectory>
</artifactItem>
</artifactItems>
<!-- other configurations here -->
</configuration>
</execution>
</executions>
</plugin>
Update:
There is a webstart-maven-plugin that does a better job of packaging javaws applications. See my sample project
https://github.com/KiranMohan/dynamic-tree-javaws-sample-project
for details

Well how i said in the comments for sake of readability here is a part of the answer:
Since Maven will always store the dependencies of a web project under its WEB-INF/lib folder by default i (i am no Maven expert ...) would try to place my lib.jar inside the /target folder of the project before the phase package is executed.
NOTE: I havent tried it out so you will have to adjust the paths - expecially the output path so your lib.jar is placed properly to be packed into the root of the war (e.g. if you open your war there will be a lib.jar next to folders such as WEB-INF).
<!--
lets assume the root of my project would be under C:/devjba/projectX this equals the maven
variable ${project.basedir}.
from there the output-directory would be located under C:/devjba/projectX/target which equals the
maven variable ${project.build.directory}. This is the location a .war would be placed in after
the build
lets assume the required jar lib.jar is located under C:/devjba/projectX/misc which would equal to
the expression: ${project.basedir}/misc
-->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>foo</id>
<!-- may adjust to another phase before package but make sure your plugin is bound to a phase
because otherwise it wont be invoked during build! Now its bound to the first phase of the
default lifecycle for packaging type war -->
<phase>process-resources</phase>
<goals>
<!-- use the copy-resources goal of this plugin - it will copy resources :) -->
<goal>copy-resources</goal>
</goals>
<configuration>
<!-- this points to /target of the current project, you may adjust it to wherever it must be placed to be packed into the root of the war (just try&error) -->
<outputDirectory>${project.build.directory}</outputDirectory>
<resources>
<resource>
<!-- this points to a folder /misc under the project root where we expect the lib.jar -->
<directory>${project.basedir}/misc</directory>
<!-- unless you specify what to include anything of the above directory will be included -->
<includes>
<include>lib.jar</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
As i said i have no experience in signing JARs at all but there is a plugin called maven-jarsigner-plugin which i guess will do the job (i would sign it, then move it, then package the war) with a manual - i recomend you try to configure it according to my "example configuration of the maven-resource-plugin and post a new question directly containing your two plugin configurations. Dont forget to link to this question in that case. And also leave this question open so someone with a better approach may correct my way).

How to change the default output from a Maven 2 / Cobertura instrument goal?

when i instrument my classes using Maven 2 using the command
mvn cobertura:instrument
The output (the instrumented classes) are put in \target\generated-classes. Is there a way to change the output location to \target\classes?
I checked the instrumentation tasks of the cobertura-maven plugin but this does not give me a solution sofar.

You have not said why you want to overwrite the default location, but I assume it is so that you can use the instrumented classes from another project, or perhaps include them in a web archive or something similar.
I added the following to my pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>instrumented-classes</id>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
<configuration>
<classifier>instrumented</classifier>
<classesDirectory>${project.build.directory}/generated-classes/cobertura</classesDirectory>
</configuration>
</execution>
</executions>
</plugin>
This makes maven generate an additional jar file called projectname-instrumented.jar
It is then possible to depend on this jar file from any other pom (including for example a web module) using
<depends>
<group>mygroup</group>
<project>projectname</project>
<version>1</version>
<classifier>instrumented</classifier>
</depends>
I did not test this 100% but have used similar mechanisms in the past

As far as I understand, the instrumented classes are only needed by cobertura for report generation. If you create them in target/classes, they will overwrite the original class files.
If you need the instrumented files in a jar as a result, you can configure the maven-jar-plugin to pick up the files from the target/generated-classes directory instead of or in addition to the files from the standard ${build.project.outputDirectory}.
Edit
Have a look at the maven-jar-plugin description. To only use target/generated-classes, the following addition to your POM should work - try it and modify it to your needs:
<project>
...
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3</version> <!-- replace with correct version nbr! -->
<configuration>
<includes>
<include>${project.build.directory}/generated-classes/**/*.class</include>
</includes>
<excludes>
<exclude>${project.build.directory}/classes/**/*.class</include>
</excludes>
</configuration>
</plugin>
...
</plugins>
</build>
...
</project>
${project.build.directory} points to your target folder, ${project.build.ouputDirectory} to target/classes. I do not know if you can simply set ${project.build.ouputDirectory} to a new value - have a look at the this chapter of the maven book, maybe you find some hints
Edit 2
Alternativly or additionally you can use maven to copy the files from target/generated-classes to target/classes after coberture:instrument has finished. This question has one answer with an example POM (fragment), you just have to identify the correct phase (process-resources is definitely too early for your case)

Did you try "mvn cobertura:instrument install"? It will generate a jar file including all the cobertura version classes.
If you want to change back original version, just run the command without "cobertura:instrument".

I just implemented the solution proposed by Andreas_D, modified my pom and uses the maven-resources-plugin. So on some stage of my build the Cobertura generated files are copied to the /target/classes directory.

You can configure it using <classesDirectory>[Your DIR]</classesDirectory>

In cobertura-maven-plugin version 2.4 this is still not supported. I've just created an improvement ticket, patch is attached to the ticket.