We have been releasing our project via Jenkins pipeline. We have a shared pipeline and the mvn release command executes with options
"'-Dgoals=deploy -DpushChanges=false -DlocalCheckout=true -DpreparationGoals=initialize ' +
'-Darguments="-Dmaven.javadoc.skip=true -Dskip.master=true" -DtagNameFormat="#{project.version}" ' +
'-Dresume=false'".
With one of recent project during maven release phase , it fails stating " Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on project myProject: Cannot prepare the release because you have local modifications :
14:00:25 [main] ERROR org.apache.maven.cli.MavenCli - [myProject/src/main/java/com/schema/avro/GlobalLinePlanStyle.java:modified].
This file is an autogenerated file for avro schema, which is generated by adding the below plugin in pom.xml
<plugin>
<groupId>org.apache.avro</groupId>
<artifactId>avro-maven-plugin</artifactId>
<version>${avro.version}</version>
<configuration>
<sourceDirectory>${project.basedir}/src/main/resources/</sourceDirectory>
<outputDirectory>${project.basedir}/src/main/java/</outputDirectory>
<fieldVisibility>PRIVATE</fieldVisibility>
<includes>
<include>**/*.avsc</include>
</includes>
<testIncludes>
<testInclude>**/*.test</testInclude>
</testIncludes>
</configuration>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>schema</goal>
</goals>
</execution>
</executions>
</plugin>
I have tried adding the explicit maven release plugin in pom.xml as below but that also have not solved the issue
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<checkModificationExcludes>
<checkModificationExclude>com/schema/avro/GlobalLinePlanStyle.java</checkModificationExclude>
</checkModificationExcludes>
</configuration>
</plugin>
Since release:prepare expects to find "filters" in checkModificationExcludes configuration setting:
A list of additional exclude filters that will be skipped when checking for modifications on the working copy. Is ignored, when checkModificationExcludes is set.
you need to specify either path relative to project root, i.e.:
<checkModificationExcludes>
<checkModificationExclude>src/main/java/com/schema/avro/GlobalLinePlanStyle.java</checkModificationExclude>
</checkModificationExcludes>
or ant pattern:
<checkModificationExcludes>
<checkModificationExclude>**/com/schema/avro/GlobalLinePlanStyle.java</checkModificationExclude>
</checkModificationExcludes>
BTW, I do not like such setup, because in my opinion generated source files must not reside in the project structure at all, however other developers report they experience other difficulties with proper setup of avro-maven-plugin.
actually, I generate a maven site containing the documentation of my project. It works very well, in fact if works so well that my customers wants to get that site as a deliverable (for obvious documentation purpose).
How can I tell Maven to build a zip of the whole site and deploy it to my artifacts manager (Nexus)? I've tried several things, but if I understand correctly, deploying artifacts and generating the site are using different livecycle, and the site generation occurs after the deployment of the artifacts..
I could obviously get the generated site from the location it's deployed during site-deploy, but I would greatly appreciate an automatic and centralized way...
PS: giving access to the customer to our internal site is NOT an option.
Here is a working solution delegated to a Maven profile to isolate the behavior (and speed-up normal builds), but which could also be integrated in the default build if required (although not recommended).
<profiles>
<profile>
<id>site-zip</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.4</version>
<executions>
<execution>
<id>pack-site</id>
<phase>prepare-package</phase>
<goals>
<goal>site</goal>
<goal>jar</goal>
</goals>
<configuration>
<attach>false</attach>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.coderplus.maven.plugins</groupId>
<artifactId>copy-rename-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>rename-file</id>
<phase>prepare-package</phase>
<goals>
<goal>rename</goal>
</goals>
<configuration>
<sourceFile>${project.build.directory}/${project.build.finalName}-site.jar</sourceFile>
<destinationFile>${project.build.directory}/${project.build.finalName}-site.zip</destinationFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<goals>
<goal>attach-artifact</goal>
</goals>
<phase>package</phase>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}-site.zip</file>
<type>zip</type>
<classifier>site</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
What the profile is actually doing:
Configuring an execution of the Maven Site Plugin, attached to the prepare-package phase and running the site and jar goals (as also suggested by #khmarbaise).
Renaming the file from jar to zip via the Copy Rename Maven Plugin
Attaching the zip to the build via the Build Helper Maven Plugin and its attach-artifact goal
As such, running
mvn clean install -Psite-zip
Will also install in your local Maven cache the zipped site. The deploy phase would do the same on your target Maven repository then.
Note that the Maven Site Plugin and the Copy Plugin must be declared in the order above to follow the required flow within the same phase.
Also note that if zip is not a strong requirement, you can then just skip the Copy and Build Helper executions and only use the Maven Site execution. By default the jar created providing the site is already attached to the build (and hence it will be installed and deployed automatically). In order to have the zip, we had to disable this behavior (<attach>false</attach>) and re-attach it via the Build Helper plugin.
The generated zipped has automatically a classifier, which is site in this case.
You can use the maven-site-plugin.
I have the following situation:
masterpom.xml:
...
<modules>
<module>sample-module</module>
</modules>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.1</version>
<inherited>true</inherited>
<executions>
<execution>
<id>update-parent</id>
<phase>pre-clean</phase>
<goals>
<goal>update-parent</goal>
</goals>
<configuration>
<parentVersion>4.4.2.1</parentVersion>
</configuration>
</execution>
</executions>
</plugin>
...
I would like to execute the versions-maven-plugin's update-parent goal on every module listed between <modules> and </modules>.
How can I do that? This configuration that I already tried doesn't work, because the modules do not inherit from masterpom.xml (they have a different parent which shouldn't be modified).
I also tried running the plugin from the command line:
mvn versions:update-parent "-DparentVersion=[4.4.2.1]"
but the changes will not be limited to the modules I want.
EDIT: running the plugin from the command line at the appropriate location seems to work. I still don't know how to produce the same effect by specifying options inside the POM.
I am having issues with sonar picking up the jacoco analysis report. Jenkins however is able to pick up the report and display the results.
My project is a maven build, built by Jenkins. The jacoco report is generated by maven (configured in the pom). Sonar is executed by using the Jenkins plugin.
This is what I see on SonarQube:
This is the report i can see of the project in jenkins.
The maven plugin config:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.6.4.201312101107</version>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>default-report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>default-check</id>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
Jenkins Sonar Plugin config
You were missing a few important sonar properties, Here is a sample from one of my builds:
sonar.jdbc.dialect=mssql
sonar.projectKey=projectname
sonar.projectName=Project Name
sonar.projectVersion=1.0
sonar.sources=src
sonar.language=java
sonar.binaries=build/classes
sonar.tests=junit
sonar.dynamicAnalysis=reuseReports
sonar.junit.reportsPath=build/test-reports
sonar.java.coveragePlugin=jacoco
sonar.jacoco.reportPath=build/test-reports/jacoco.exec
The error in Jenkins console output can be pretty useful for getting code coverage to work.
Project coverage is set to 0% since there is no directories with classes. Indicates that you have not set the Sonar.Binaries property correctly
No information about coverage per test Indicates you have not set the Sonar.Tests property properly
Coverage information was not collected. Perhaps you forget to include debug information into compiled classes? Indicates that the sonar.binaries property was set correctly, but those files were not compiled in debug mode, and they need to be
Based on https://github.com/SonarSource/sonar-examples/blob/master/projects/tycho/pom.xml, the following POM works for me:
<properties>
<sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.0.201403182114</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
</executions>
<configuration>
<destFile>${sonar.jacoco.reportPath}</destFile>
</configuration>
</plugin>
</plugins>
</build>
Setting the destination file to the report path ensures that Sonar reads exactly the file JaCoCo generates.
The report path should be outside the projects' directories to take cross-project coverage into account (e.g. in case of Tycho where the convention is to have separate projects for tests).
The reuseReports setting prevents the deletion of the JaCoCo report file before it is read! (Since 4.3, this is the default and is deprecated.)
Then I just run
mvn clean install
mvn sonar:sonar
I had the similar issue, 0.0% coverage & no unit tests count on Sonar dashboard with SonarQube 6.7.2:
Maven : 3.5.2,
Java : 1.8,
Jacoco : Worked with 7.0/7.9/8.0,
OS : Windows
After a lot of struggle finding for correct solution on maven multi-module project,not like single module project here we need to say to pick jacoco reports from individual modules & merge to one report,So resolved issue with this configuration as my parent pom looks like:
<properties>
<!--Sonar -->
<sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
<sonar.language>java</sonar.language>
</properties>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.4.0.905</version>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.9</version>
<configuration>
<destFile>${sonar.jacoco.reportPath}</destFile>
<append>true</append>
</configuration>
<executions>
<execution>
<id>agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
I've tried few other options like jacoco-aggregate & even creating a sub-module by including that in parent pom but nothing really worked & this is simple. I see in logs <sonar.jacoco.reportPath> is deprecated,but still works as is and seems like auto replaced on execution or can be manually updated to <sonar.jacoco.reportPaths> or latest. Once after doing setup in cmd start with mvn clean install then mvn org.jacoco:jacoco-maven-plugin:prepare-agent install (Check on project's target folder whether jacoco.exec is created) & then do mvn sonar:sonar , this is what I've tried please let me know if some other best possible solution available.Hope this helps!! If not please post your question..
Jenkins does not show coverage results as it is a problem of version compatibilities between jenkins jacoco plugin and maven jacoco plugin.
On my side I have fixed it by using a more recent version of maven jacoco plugin
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.9</version>
</plugin>
<plugins>
<pluginManagement>
<build>
I was facing the same problem and the challenge in my case was to configure Jacoco correctly and to configure the right parameters for Sonar. I will briefly explain, how I finally got SonarQube to display the test results and test coverage correctly.
In your project you need the Jacoco plugin in your pom or parent pom (you already got this). Moreover, you need the maven-surefire-plugin, which is used to display test results. All test reports are automatically generated when you run the maven build. The tricky part is to find the right parameters for Sonar. Not all parameters seem to work with regular expressions and you have to use a comma separated list for those (documentation is not really good in my opinion). Here is the list of parameters I have used (I used them from Bamboo, you might omit the "-D" if you use a sonar.properties file):
-Dsonar.branch.target=master (in newer version of SQ I had to remove this, so that master branch is analyzed correctly; I used auto branch checkbox in bamboo instead)
-Dsonar.working.directory=./target/sonar
-Dsonar.java.binaries=**/target/classes
-Dsonar.sources=./service-a/src,./service-b/src,./service-c/src,[..]
-Dsonar.exclusions=**/data/dto/**
-Dsonar.tests=.
-Dsonar.test.inclusions=**/*Test.java [-> all your tests have to end with "Test"]
-Dsonar.junit.reportPaths=./service-a/target/surefire-reports,./service-b/target/surefire-reports,
./service-c/target/surefire-reports,[..]
-Dsonar.jacoco.reportPaths=./service-a/target/jacoco.exec,./service-b/target/jacoco.exec,
./service-c/target/jacoco.exec,[..]
-Dsonar.projectVersion=${bamboo.buildNumber}
-Dsonar.coverage.exclusions=**/src/test/**,**/common/**
-Dsonar.cpd.exclusions=**/*Dto.java,**/*Entity.java,**/common/**
If you are using Lombok in your project, than you also need a lombok.config file to get the correct code coverage. The lombok.config file is located in the root directory of your project with the following content:
config.stopBubbling = true
lombok.addLombokGeneratedAnnotation = true
Include the sunfire and jacoco plugins in the pom.xml and
Run the maven command as given below.
mvn jacoco:prepare-agent jacoco:report sonar:sonar
<properties>
<surefire.version>2.17</surefire.version>
<jacoco.version>0.7.2.201409121644</jacoco.version>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire.version}</version>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals><goal>prepare-agent</goal></goals>
</execution>
<execution>
<id>default-report</id>
<phase>prepare-package</phase>
<goals><goal>report</goal></goals>
</execution>
</executions>
</plugin>
</plugins>
The presence of argLine configurations in either of surefire and jacoco plugins stops the jacoco report generation. The argLine should be defined in properties
<properties>
<argLine>your jvm options here</argLine>
</properties>
For me percentage coverage was not appearing in the sonarqube dashboard. I have added below property in our pom.xml to work.
<sonar.binaries>${project.basedir}/../target/classes</sonar.binaries>
Make sure that Sonarqube can find your test coverage file.
As somebody already mentioned the Sonarqube output should really be helpful here.
e.g.
WARN: No coverage information will be saved because LCOV file cannot be found.
Can the Maven Sortpom Plugin affect the result of a project's build ?
Is it possible to have a project build fail just because the sortpom plugin was added ?
Normally the order of the elements in a pom.xml file does not matter, so reordering elements should not affect the build.
But I know of two exceptions to this rule:
Maven reads dependencies according to the order in the pom-file when compiling. Rearranging that order may affect the compilation output.
If two plugins executes in the same phase, the order in pom-file will determine which plugin to execute first. Sorting the plugins may cause the compilation to fail if the result of one plugin is dependent on another.
The sortpom plugin does not sort either dependencies nor plugins by default. So I would say that the sortpom plugin should not affect the result of a projects build.
It can fail a build:
[ERROR] Failed to execute goal com.google.code.sortpom:maven-sortpom-plugin:2.3.0:sort (default) on project data-extractor: scm.team.company.corp: Unknown host scm.team-project.company.corp -> [Help 1]
The if the file isn't found due to network problems, even when running with -o
Yes.
For example, you use:
org.codehaus.mojo:build-helper-maven-plugin's reserve-network-port goal in phase pre-integration-test
org.apache.tomcat.maven:tomcat7-maven-plugin's run goal also in phase pre-integration-test
Now, sortpom:sort orders them around, and in maven-3, the order of the plugins are important. So if you configure a random port for tomcat through the portName feature of reserve-network-port, the system property won't be filled (at the point it is needed), as after the sort, the build-helper artifact is executed AFTER the run goal is invoked.
Example after a sorting:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<id>start-tomcat</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<fork>true</fork>
</configuration>
</execution>
<!-- ... -->
</executions>
<configuration>
<fork>true</fork>
<port>${tomcat.http.port}</port><!-- Oops, not set (yet)! -->
</configuration>
</plugin>
<!-- ... -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>${build-helper.version}</version>
<executions>
<execution>
<id>reserve-tomcat-port</id>
<phase>pre-integration-test</phase>
<goals>
<goal>reserve-network-port</goal>
</goals>
<configuration>
<portNames>
<portName>tomcat.http.port</portName><!-- Too late -->
</portNames>
</configuration>
</execution>
</executions>
</plugin>