During the maven release:perform goal, the prepared tag is being checked out from SCM and a build seems to be attempted in a forked maven instance.
I'd like the tests to be skipped at that point, because for whatever reason, they fail (the build involves running a test web-application via cargo, and I believe this just doesn't work well in this environment).
Is there any way to instruct maven to do this?
You can specify arguments to the forked maven instance on the command line:
mvn release:prepare -Darguments="-DskipTests"
mvn release:perform -Darguments="-DskipTests"
or specify a maven-release-plugin configuration in your pom, perhaps under pluginManagement:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<arguments>-DskipTests</arguments>
</configuration>
</plugin>
Related
When release:clean release:prepare release:perform is executed , the tests are executed twice
Once at release:prepare , stage run-preparation-goals , task clean verify
And another time on release:perform ,stage run-perform-goals , task deploy
Is there any configuration option to make tests run only on first one and not being executed on perform?
BR
Yulian Oifa
That's because 2 full builds are run as part of the commands you issue.
The release:prepare section performs lots of checks on the code & repository, and does a full build to ensure all tests pass.
The release:perform section tags the repo, then pulls that tag. It performs a build based on that tag and the releases that build to your artefact store of choice (Nexus/Artifactory/wherever).
These steps are designed this way to ensure you don't pollute your repo with a tag on code that doesn't build, and tests are an integral part of your build. Once maven is happy your code is good to go, it creates the tag, and pulls it so it knows for sure that the code being released is the code referenced by the tag, and nothing else. Building that tag for release requires a full build, including the tests.
You can skip the tests on one or other of the steps, or on both, but you're missing the point of tests, and of the release plugin, if you do that.
You can override the goals parameter and add -DskipTests=true.
This parameter will skip the tests only on the perform part.
Eventually i had to change a logic.
I have executed mvn clean install release:clean release:prepare release:perform -Pmaven-release
and create a maven-release. As result the tests are executed only at install
BR
Yulian Oifa
<profile>
<id>maven-release</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<autoVersionSubmodules>true</autoVersionSubmodules>
<arguments>-Dmaven.test.skip</arguments>
</configuration>
</plugin>
</plugins>
</build>
</profile>
You can skip running the tests (managed by surefire plugin) with an explicitly specified parameter -DskipTests:
Something like this:
mvn release:perform -DskipTests
For intergration tests (managed by failsafe plugin) you can use a similar flag: -DskipITs
If you don't want even compile the tests you can use -Dmaven.test.skip=true (for both unit and integration tests)
When I run the release:prepare Maven goal it asks me for the version three times: release, release, next-snapshot.
Is it possible to force the second one to be always like the first one?
What is the release version for "app1"? (org.dep1:app1) 1.0.9: :
What is the SCM release tag or label for "app1"? (org.dep1:app1) 1.0.9: :
What is the new development version for "app1"? (org.dep1:app1) 1.0.10-SNAPSHOT: :
I would prefer to always have the git tag identical to the version number, and ideally skip the second question.
Here's my Maven Release Plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<tagNameFormat>#{project.version}</tagNameFormat>
<autoVersionSubmodules>true</autoVersionSubmodules>
</configuration>
</plugin>
The simplest step is to use batch mode which can be done like this:
mvn -B release:prepare release:perform
This will use the defaults without asking for anything.
If you want to set the releaseVersion you can do that via:
mvn -B release:prepare release:perform -DreleaseVersion=2.0.0
To control which development version will be used you can set this by adding-D developmentVersion=2.1.0-SNAPSHOT if you don't like the default.
I have been struggling to fix my maven build issue from last 2 days with no success almost. Can you please help me on this?
I have a parent pom.xml which looks like
<distributionmanagement>
Repository...
Snapshot
<site>
site config here..
</site>
</distributionmanagement>
In child pom.xml, which I wrote works fine if I do 'mvn install'. tar file is created and appears in project/target folder. Looks good so far...
When I do release the problem comes. The good thing is, it goes well till end - creates tar, uploads tar into my svn repository.. but after that maven is trying to read parent pom.xml and error comes while running "maven-site-plugin:default-deploy" and then "BUILD FAILURE"
What I'm thinking is - since tar is created and uploaded into subversion repository creating site & deploying is not required for us. How can I say to maven that once tar is created don't do anything and that's the end point for me. In other words - don't run anything 'site' related stuff for me?
=========================
UPDATE
I have my release plugin config as below
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tagBase></tagBase>
</configuration>
</plugin>
we actually do release from our batch file which consists of mvn statements like below -
call mvn clean
call mvn install
call mvn -B release:prepare -DdryRun=true -DscmCommentPrefix="somecomment"
call mvn -B release:clean
call mvn -B release:prepare -DscmCommentPrefix="somecomment"
call mvn -B release:perform -DscmCommentPrefix="somecomment"
Can you please suggest me now?
You should change the maven-release-plugin configuration no to do an site-deploy which is default like the following:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<goals>deploy</goals>
</configuration>
</plugin>
Or if creating site & deploying is really not required (as you say in your question), you could just remove the <distributionManagement> section. According to the docs default goals are "either deploy or deploy site-deploy, if the project has a <distributionManagement>/<site> element".
http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html
My Maven project has a bunch of subprojects like this:
proj/
projEAR/
projCommon/
How can I compile and build the EAR project + deploy it to my web server at the same time?
The way I do it now is:
proj$ mvn clean install
[... builds everything ... ]
proj$ cd projEAR
projEAR$ mvn weblogic:deploy
[... deploys the EAR file ... ]
I'd like to do this with one command. Something like
proj$ mvn clean install projEAR/pom.xml weblogic:deploy
This fails of course, but I hope you get the idea...
Update:
The reason for all this is that jenkins only accepts one pom-file and command. So the problem is really how to configure Jenkins to run Maven twice.
How about the weblogic-deployer-plugin of Jenkins. It will deploy your ear file to a weblogic instance. See WebLogic Deployer Plugin.
Quick and easy workaround
As a workaround, I can advise you to use some Jenkin's Plugins, like "M2 Extra Steps". It allow you to perform extra actions pre or post one. They are often use after a build to perform stuff like generating doc, or deploying something.
I know this is working well ... because I often use this trick :)
Suggestion, never tried
At this moment, I don't have a straight answer. I don't really know how to do it in only one maven command. What I would try is to attach weblogic deploy phase to install.
ear submodule --> pom.xml
<build>
[...]
<plugins>
[...]
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>2.9.1</version>
<executions>
<execution>
<configuration>
[...]
</configuration>
<goals>
<goal>install</goal>
</goals>
</execution>
</executions>
</plugin>
[...]
<plugins>
[...]
<build>
It should work, but once again, I never tried it.
Don't hesitate to give feed back
I couldn't get it to work with Maven. But the way I solved it (in Jenkins) was
Create a pre-build step in Jenkins with the command mvn clean install using the parent pom: proj/pom.xml
Configure the main build as weblogic:deploy using projEAR/pom.xml.
This results in two commands being run: First mvn clean install followed by mvn weblogic:deploy.
I have a need to active a profile during release:prepare.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<arguments>-Prelease</arguments>
<preparationGoals>clean validate</preparationGoals>
<goals>test-compile</goals>
</configuration>
</plugin>
</plugin>
</build>
But when I run:
mvn release:prepare -DdryRun=true help:active-profiles
it never show profile release in active list. and it is not show up on active profile list when I do:
mvn release:perform help:active-profiles
I could not not use <releaseProfiles> since I want this profile to be used in both prepare and perform
Thanks!
One thing that I have used in this case is not using the -P argument, but rather triggering the profile through an environment setting using -Denv=release. Then in the POM, I have the profile activation based on the value of env. This has always worked for me. So in the arguments parameter, you could put something like
<arguments>-Denv=release</arguments>
Similar questions can be found here:
Profile activation on both release:prepare and release:perform
maven release plugin ignores releaseProfile
I think there's some misunderstanding here: mvn release:prepare -DdryRun=true help:active-profiles will never show the active profiles used during the release, but it shows the current active profiles. release:prepare will start another Maven thread (separate executable), and only then the release profile is activated.
In the maven-release-plugin-2.4 a lot has been fixed with regards to profiles, especially for Maven3, since some information was not available anymore when using Maven 2 but now is with Maven 3.
See the release notes