I have a pom with the following GAV
<groupId>com.company.services</groupId>
<artifactId>test-branch-2</artifactId>
<version>1.0.21-SNAPSHOT</version>
I want to remove -SNAPSHOT from this using maven in batch mode, so I can do it with Jenkins and not have to specify anything manually.
I've looked at the documentation for version:set but all the options offer me an interactive prompt and ask me to type a name for the version.
I would prefer the versions plugin, not the release plugin.
Since version 2.10 of the Versions Maven Plugin you can simply do:
mvn versions:set -DremoveSnapshot
If you really don't want to use the Maven Release Plugin (for whatever reason), here is how I succeed on dropping the SNAPSHOT suffix (hanbdled as a classifier) from a maven POM in a standard way (that is, no scripting, no custom maven plugin).
Given the following profile:
<profile>
<id>drop-snapshot</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.11</version>
<executions>
<execution>
<id>parse-version</id>
<phase>validate</phase>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>set-version</id>
<phase>validate</phase>
<goals>
<goal>set</goal>
</goals>
<configuration>
<newVersion>${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.incrementalVersion}</newVersion>
</configuration>
</execution>
<execution>
<id>upgrade-pom</id>
<phase>validate</phase>
<goals>
<goal>commit</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
And simply executing: mvn validate -Pdrop-snapshot
The version of an example pom passed from 0.0.1-SNAPSHOT to 0.0.1.
How it actually works:
The build-helper-maven-plugin, parse-version goal, will parse the current version of the POM and set it in a set of properties having by default parsedVersion as a prefix and majorVersion, minorVersion, incrementalVersion as suffixes (check the documentation, you will also have classifier and buildNumber). Hence, after its execution we can then use in our POM the properties like ${parsedVersion.majorVersion} and so on.
The versions-maven-plugin, set goal, will then use these properties to build the new version you actually want (in this case dropping the SNAPSHOT, because we excluded the ${parsedVersion.classifier} property).
Lastly, the versions-maven-plugin, commit goal, will make these changes effective.
Similar to A_Di-Matteo's approach with build-helper, but without the need for additional plugins configuration:
mvn build-helper:parse-version versions:set \
-DnewVersion=\${parsedVersion.majorVersion} \
.\${parsedVersion.minorVersion} \
.\${parsedVersion.incrementalVersion \
.\${parsedVersion.buildNumber} \
versions:commit
This will replace your 1.0.0.0-SNAPSHOT with 1.0.0.0 in the pom.xml.
Add the following to your POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.11</version>
<configuration>
<name>newVersion</name>
<value>${project.version}</value>
<regex>-SNAPSHOT</regex>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.2</version>
</plugin>
</plugins>
</build>
You can now remove the -SNAPSHOT part of your project's version with:
mvn build-helper:regex-property versions:set -N
The -N tells Maven to only proces the root project in case you have modules defined in your POM. This is not strictly necessary but prevents the build-helper plugin from running unnecessarily against the submodules. The versions plugin runs only on the root project in any case, and traverses all modules automatically. Consider using the reactorModuleConvergence rule of the maven-enforcer plugin to make sure multi-module projects are handled correctly.
You can run mvn versions:commit to remove the backup POM(s) generated by versions:set. Alternatively you can add <generateBackupPoms>false</generateBackupPoms> to the configuration of the versions plugin.
Related
I use the Versions Maven Plugin to check for updates of my dependencies. Therefore I added the following lines to my pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>${versions-plugin.version}</version>
<configuration>
<rulesUri>classpath:///rules.xml</rulesUri>
</configuration>
<dependencies>
<dependency>
<groupId>versionrules</groupId>
<artifactId>versionrules</artifactId>
<version>1-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
But this configuration is not used if I run the Versions Maven Plugin from the commandline in the same directory as the pom.xml. The only way to use my own configuration is to put this plugin configuration in a profil and execute this profil during the Maven run.
Is there a way to run the Versions plugin on the commandline and to configure it via the pom.xml? I am sure my questions does not only apply to the Versions plugin, but to any Maven plugin.
This can be done by using an execution id default-cli in your execution definition the configuration will be used during the execution on command line (using the current configuration) furthermore since Maven 3.3.1 you can use things like:
mvn version:set#second-cli
which means you can do a different configuration for command line in the pom file:
Just by simply separating them by different id
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.5.</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
...
</configuration>
</execution>
<execution>
<id>second-cli</id>
<configuration>
....
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
So this means you can have different configurations for running on command line by giving the id.
Easy question here. I want to add sonar to be executed on every Maven build. I tried:
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.1.1</version>
</plugin>
and
<plugin>
<groupId>org.codehaus.sonar</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>5.1</version>
</plugin>
and
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>2.7.1</version>
</plugin>
because a) I couldn't figure out what the plug-ins do and/or b) which one is the current one.
If I only add the above to <build> -> <plugins> it's not executed ever (so the plug-in doesn't have a default execution). So of course I added a <execution> instruction, and after that Sonar gets executed, but with the following error message:
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>sonar</goal>
</goals>
</execution>
</executions>
Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.1.1:sonar (default) on project org.acme.project.build: Can not execute Findbugs: This project contains Java source files that are not compiled.
It does not seem to matter which phase I use (I tried validate and compile and test and prepare-package and package even though not all of them make sense). I am sure there is no source code generation anywhere in the project. And the static classes get compiled just fine.
I think the problem might be that the plug-in gets executed for every module, including the parent pom project. Which is weird, because sonar:sonar skips that project.
But the project structure is simple and I can't find anything unusual about it:
<groupId>group</groupId>
<artifactId>org.acme.project.build</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>org.acme.project</module>
</modules>
<profiles>
<profile>
<id>sonar</id>
<properties>
<sonar.host.url>http://sonar.acme.org/</sonar.host.url>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>sonar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
The project org.acme.project has nothing besides its own artifact ID and the parent. The command line is: mvn clean deploy -Dsonar.login=Wile.Coyote -Dsonar.password=*********** -Psonar
The log shows that sonar is always executed before the install phase, which of course is way to early.
So how do I use Sonar's Maven plug-in to analyze my code?
a) I couldn't figure out what the plug-ins do
The plugin is used to gather the details from code coverage reports and the repository code scanning for getting to analyze possible bugs, duplications etc. You can search for a sample sonar report to find what all and how to get these details with maven using two methods like settings.xml and maven plugin is detailed at SonarQube Scanner for Maven and
SonarQube - analyzing with Maven
b) which one is the current one.
The maven central suggests that the current plugin from org.codehaus.mojo used as
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.2</version>
</plugin>
has been moved to
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.2</version>
</plugin>
So you should ideally be using the one from groupId - org.sonarsource.scanner.maven as also suggested by the SonarQube Docs
Also the artifact from org.codehaus.sonar version 5.1 seems to be outdated and not maintained.
When I run $mvn -q clean install, I see a bunch of [debug] execute contextualize statements printed to the console.
After doing some searching, I determined that this is a problem with version 2.5 of the Maven Resources Plugin. This problem has been fixed in version 2.6, but I cant figure out how to get my project to use it. (http://jira.codehaus.org/browse/MRESOURCES-140)
None of my projects have this plugin listed in their poms, so I am not sure where Maven is getting it from, maybe it is used in one of the other Apache dependencies or something? (I don't really even understand what this plugin does or how plugins in Maven are used in general)
I tried adding the following to my root pom:
<build>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
</plugin>
</plugins>
</build>
However, this doesn't seem to solve the problem. I still see the [debug] execute contextualize output and when I run $mvn help:effective-pom, the output still shows:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>default-resources</id>
<phase>process-resources</phase>
<goals>
<goal>resources</goal>
</goals>
</execution>
<execution>
<id>default-testResources</id>
<phase>process-test-resources</phase>
<goals>
<goal>testResources</goal>
</goals>
</execution>
</executions>
</plugin>
How can I force Maven to use the newer version of this plugin so that I can suppress the annoying [debug] execute contextualize outputs?
Try do add the groupId of the plugin in your build settings :
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
</plugin>
</plugins>
</build>
The maven-resources-plugin is bound to the lifecycle by default for jars, wars, & ears. Adding a definition to your corporate root POM as you did should work to update the version used. Things to check:
Is the inheriting project specifying the version of the corporate parent POM that includes the change?
Did you run mvn clean install on the root POM prior to running the project build?
If the answer is "yes" and "yes", try cleaning out your local artifact repo, then run mvn clean install for the root, and try the build again.
I have a need to only run a specific jUnit when the mvn release:prepare is executed. I don't want this to run under mvn install or any other goal as this jUnit is designed to see if the developer has executed a database activity first.
Is there any way to either have the junit know, by parameter(?), that the process under execution is release:prepare?
Or, is there a way to define within the pom.xml that this jUnit only runs on that goal?
I've been doing some searching on this and I cannot seem to find a solution as I'm not that good at maven as of yet. Any help is appreciated!
I haven't done exactly what you want but the key is to use the <executions> section under the SureFire :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
... exclude the test from normal execution ...
</configuration>
<executions>
<execution>
<id>release-phase</id>
<phase>release-prepare</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
... fill this in to include the tests you want ...
</configuration>
</execution>
</executions>
<plugin>
You will also want to exclude that test in the normal <configuration> section.
There is some related information HERE
Others are close... but no cigar.
When Maven runs a release, there are no special phases for the release process. What you want to do is add a profile that is configured to include the test you want, e.g.
<profiles>
<profile>
<id>release-preflight-checks</id>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>release-preflight-checks</id>
<goals>
<goal>test</goal>
</goals>
<configuration>
.. include your test here
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Then you need to configure surefire by default to not execute your preflight check
<build>
<plugins>
...
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
.. exclude your test here
</configuration>
</plugin>
...
</plugins>
</build>
And then finally, you need to tell Maven that this profile should be active only during release:prepare's forked execution
<build>
<plugins>
...
<plugin>
<artifactId>maven-release-plugin</artifactId>
<configuration>
...
<preparationGoals>clean verify -P+release-preflight-checks</preparationGoals>
...
</configuration>
</plugin>
...
</plugins>
</build>
Note: it is vitally important to have the + in front of the profile name so that you are adding the profile to the list of active profiles otherwise your release:prepare step will not be validating that the build works with the release profile active and you can have a subsequent release:perform fail.
Note: A less complex route would be to just put the surefire configuration into the release profile that you are using (by default that has the id of release but that is more error prone as you could change that via the parent pom - e.g. if you decide to push your project to central, the sonatype-oss-parent changes the release profile to sonatype-release - and then you won't see the build being failed as the test would not be executed until you change your pom to match new the release profile's id... using the -P+release-preflight-checks ensures that the profile is always active for release:prepare and additionally has the benefit of meeting the requesters original requirement completely - i.e. only runs for release:prepare and doesn't run for release:perform which would be the case if the execution was added to the release profile)
I have a maven project that uses the aspectj-compiler-plugin. I use intertype declarations so there are references to Aspect code in my Java code. Because of this, the maven-compiler-plugin fails to compile since it does not compile the aspect code.
My question is: how do I disable the maven-compiler-plugin from running because it is not doing anything useful?
There are several ways that I can get this project compiling, but they are sub-optimal:
Add exclusion filters to the maven-compiler-plugin. The plugin will still run, but it will not try to compile anything. Problem is that this breaks the ajdt project configurator in Eclipse
Move all java code to the aspectj folders. This doesn't feel right either.
You can disable the a plugin by set the phase of the plugin to none.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
In Maven 3, the following will do this, for example disabling the clean plugin:
<build>
<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<id>default-clean</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
The same technique can be used for any other plugin defined in the super-POM, the packaging type, or the parent POM. The key point is that you must copy the <id> shown by help:effective-pom, and change the <phase> to an invalid value (e.g. "none"). If you don't have the <id> (as e.g. in Jintian DENG's original answer – it has since been edited to add one), it will not work, as you have discovered.
Either configure the skipMain parameter:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<skipMain>true</skipMain>
</configuration>
</plugin>
</plugins>
</build>
Or pass the maven.main.skip property:
mvn install -Dmaven.main.skip=true
The reason maven-compiler-plugin executes in the first place is because you trigger one of the default lifecycle bindings. For example if you're packaging jar using mvn package, it will trigger compile:compile at compile phase.
Maybe try not to use the default lifecycle, but use mvn aspectj:compile instead.
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html has more information about maven default lifecycle bindings