Im looking to see any maven configuration which will enable me to run Sonar Scan on my code for every maven build. I dont want to use a separate goal but somehow enforce it as part of users regular build commands.
You can attach Sonar to a phase (e.g. verify) like this:
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.5.0.1254</version>
<executions>
<execution>
<id>verify-sonar</id>
<phase>verify</phase>
<goals>
<goal>sonar</goal>
</goals>
</execution>
</executions>
</plugin>
This also works with other phases like compile or package.
Related
We have projects where we use jacoco to aggregate code coverage over several modules. We also have some project that use the Fabric8 docker-maven-plugin to run black box test. But for the first time we would now like to run them both i the same project. And it kind of works but not in the same maven command.
We can run mvn test and then jacoco does it job perfecly.
we can run mvn install -Djacoco.skip=true and the black box tests start the necessary docker-containers and run the tests on them.
But running mvn install and thus saying that both blackbox-tests and jacoco codecoverage should run will fail saying that jacoco doesn't find dependencies in a central repository (where they are not supposed to be anyway).
So, my question, what could docker-maven-plugin do to interfere with jacoco? It seems like docker-maven-plugin deletes stuff that jacoco expect to be there.
My configuration for jacoco is using the invoker-plugin (as many of the guides for multi module exampels for jacoco does) with localRepositoryPath, could it be colliding? Or do docker-maven-plugin clean the workspace? Se plugin-definition below.
<plugin>
<!-- To run with different Maven versions use -Dinvoker.mavenHome -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-invoker-plugin</artifactId>
<version>1.5</version>
<configuration>
<skipInvocation>${skipTests}</skipInvocation>
<projectsDirectory>it</projectsDirectory>
<cloneProjectsTo>${project.build.directory}/it</cloneProjectsTo>
<pomIncludes>
<pomInclude>*/pom.xml</pomInclude>
</pomIncludes>
<postBuildHookScript>verify</postBuildHookScript>
<localRepositoryPath>${project.build.directory}/local-repo</localRepositoryPath>
<goals>
<goal>clean</goal>
<goal>install</goal>
</goals>
<settingsFile>it/settings.xml</settingsFile>
<extraArtifacts>
<extraArtifact>org.jacoco:org.jacoco.agent:0.8.3:jar:runtime</extraArtifact>
</extraArtifacts>
</configuration>
<executions>
<execution>
<goals>
<goal>install</goal>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
I need to run a Maven plugin after Gatling(gatling-maven-plugin) runs to do some cleanup of my target dir.
From the following article it is called out that mvn gatling:test is bound to the integration-test phase of Maven
https://github.com/gatling/gatling/blob/65524556b1aaee7d129cc9c4794977468493ad34/src/sphinx/extensions/maven_plugin.rst#usage
Knowing this and that plugins tied to the same phase run sequentially I added a plugin after gatling-maven-plugin tied to the same integration-test phase.
Unfortunately that plugin never runs. Appreciate any advice on how to get a plugin to run after gatling-maven-plugin runs.
Snippet of what i'm trying to do below. Appreciate any advice. I do something similar and successfully with the maven-surefire-plugin by adding a plugin after that tied to the test phase and it works perfect. Scratching my head on this one.
<plugin>
<groupId>io.gatling</groupId>
<artifactId>gatling-maven-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<simulationsFolder>src/test/java</simulationsFolder>
<includes>
<include>perf.Test</include>
</includes>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>myId</id>
<phase>integration-test</phase>
<goals>
<goal>run</goal>
<configuration>
<target>
<echo message="running something after gatling"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
I find it strange that the plugin never runs.
Anyway, for cleaning up, I would use the post-integration-test phase.
same issue with teardown. Managed to do it within in gatling itself, but doesnt seem as perfect cleanup achieved! also interaction between the gatling and other plugins not possible during post-integration-phase. once gatling tests are started then the entire execution control ends with the same plugin.
I am trying to replace maven exec with MavenInvokerPlugin because of problems on Jenkins with forwarding the maven settings file.
So in bash it looks straight:
mvn dependency:copy-dependencies#resolve-maven-deps
My translation to MavenInvokerPlugin configuration is
<plugin>
<artifactId>maven-invoker-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<projectsDirectory>${project.basedir}/src/main/docker</projectsDirectory>
<localRepositoryPath>${project.build.mavenDependencies}</localRepositoryPath>
<goal>dependency:copy-dependencies#resolve-maven-deps</goal>
</configuration>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>run</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
</plugin>
It looks like that execution id is completely ignored, because I tried random strings and mvn builds the project with success.
mvn dependency:copy-dependencies#asdfasdfa
So I'd like to know whether this feature is supported at all and what I am doing wrong.
P.S. I know that calling maven out of maven is anti pattern, but here is exactly that rare case when there is no other way.
After looking at projects using maven invoker I figured out the trick.
goal tag is not used, instead provide invokerPropertiesFile:
<pom>${project.basedir}/xxx/pom.xml</pom>
<invokerPropertiesFile>${project.basedir}/invoker.properties</invokerPropertiesFile>
content of the file:
invoker.goals=compile -P resolve-maven-deps
I have several levels of nested Maven projects, where every module can participate in the global integration tests. To have a global, multi module coverage, I've configured jacoco to use and share the same file accross modules, using the Maven variable ${session.executionRootDirectory}:
<execution>
<id>pre-integration-test</id>
<phase>pre-integration-test</phase>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
<configuration>
<propertyName>jacoco.failsafeArgLine</propertyName>
<destFile>${session.executionRootDirectory}/target/jacoco-it.exec</destFile>
</configuration>
</execution>
This way, the same data file is used by each module, no matter how deep it is nested in the submodules. I've checked, a correct data file is generated by jacoco when launching "mvn clean install".
Now the problem appears when launching mvn sonar:sonar. It seems that the plugin can not replace that variable with the real path. I can see the following in the logs
[INFO] JaCoCoItSensor: JaCoCo IT report not found: /home/tomcat/.jenkins/jobs/MYJOB/workspace/${session.executionRootDirectory}/target/jacoco-it.exec
It doesn't work better when using #{session.executionRootDirectory}.
Any workaround?
Following a comment in this bug report at SonarSource, advising to use the following configuration:
<plugin>
<groupId>com.github.goldin</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>0.2.5</version>
<executions>
<execution>
<id>set-sonar.jacoco.reportPath</id>
<goals>
<goal>set-properties</goal>
</goals>
<phase>initialize</phase>
<configuration>
<rawProperties>
sonar.jacoco.itReportPath = ${session.executionRootDirectory}/target/jacoco-it.exec
</rawProperties>
<addDollar>true</addDollar>
</configuration>
</execution>
</executions>
</plugin>
... which was unfortunately not compatible with Maven 3.1+, I've used and built from sources that fork, and then I was able to make everything work correctly with Maven 3.2.3.
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>