After switching from maven 2 to maven 3 I have found out having 0% test coverage reported by cobertura. I've stated question about which versions of cobertura and surefire to use: What versions of cobertura and surefire plugins work together under maven3?
I have, however, investigated problem deeper and found out what of configuration fragment was not working:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire.plugin.version}</version>
<configuration>
<forkMode>never</forkMode>
<redirectTestOutputToFile>true</redirectTestOutputToFile>
<argLine>-Xmx512m -XX:MaxPermSize=256m</argLine>
</configuration>
</plugin>
After changing forkMode from never to once the test coverage started to be generated. So, the problem was not the plugins version incompatibility itself, but the problem with the support by various fork modes of surefire by cobertura under maven 3.
So, my question is, is it a bug, or cobertura plugin is designed in such way, that it won't work with some forkMode=never?
Cobertura is designed to output the coverage results when the JVM exits.
<forkMode>never</forkMode> instructs Maven not to fork a JVM for running the tests but to re-use the current JVM.
In this case, the coverage results may not be output until Maven completes execution.
In Maven 2, I am not 100% certain, but I think some of how the forked lifecycle (evilly) used by the cobertura plugin worked caused either a JVM fork for the forked lifecycle, or else a classloader unload effectively had the same result.
Thus in my opinion it was a bug of Maven 2 that coverage happened to work with <forkMode>never</forkMode>.
Note: <forkMode>never</forkMode> is considered quite dangerous because of how System properties are not scoped per classloader, among other issues. <forkMode>once</forkMode> is generally the best option (unless you have tests that abuse memory - some versions of JUnit keep all the test class instances in memory until reporting at the end of the run, so if each test class holds on to heavy objects, GC will be unable to clear them out as they are live until the end of the test run. In such cases a perclass/always forkMode will be required)
Related
We have a build job where the console output shows many strange messages like below, so we cannot load a full log and have to remove the -X option in the build configuration to get rid of them. I think it happened after I upgraded the Jenkins version.
Any idea of what might be causing this?
[DEBUG] http-outgoing-0 >> "j[0x5]q4/J[0x18]^di[0x86][0xbf]C_[0xd6]G[0x1d]
[0xd4][0x7][0xf3][0xc7][0x14][0xdf][0x8d][0xe1][0x13][0xd8]$y|#[0x1e][0xbf]
[0xe6][0x81]<[0xca][0x6][0xa1]~j[0x81]3[0xbc][0x98][0xd1][0x83][0xa7]
[0xc5]8[0xfa]>[0xd9]edZ[0xb2][0xc][0xe0][0x5][0xab][0xf3][0x1a]M[0xb3][0xe7]
[0x1][0xf4][\n]"
[DEBUG] http-outgoing-0 >> "[0xcd][0x9d][0x86]Zjp[0xb4][0x8d][0x87]
[0x8f]cn[0xe7][0xab]oL.[0xb2]}[0x86][0xf8]D[0x87][0xba][0x9d][0xcc]j[0x15]
[0xa4][0xe6]![0x9f]_BBC[0xbf]j[0xab]Rl[0x10][0x92][0xc5])[0xb2][0xc5]i[0xc2]
I encountered this exact problem right around the same time (April 2018), and found that it was being triggered by Artifactory plugin 2.15.0 (and later). For over a year, I had left that plugin downgraded in order to avoid having DEBUG logging in my build logs. Although this worked for me (until I was forced to upgrade last week due to an incompatibility with new versions of Artifactory), it is possible that a different plugin or jar file in your classpath is causing the problem in your case.
After spending an entire weekend troubleshooting this problem, I finally found the underlying cause in my build environment.
The important points are:
This is a problem with the classpath of the build process (e.g., Ant).
This is not a configuration problem with Jenkins.
This cannot be fixed via the project configuration.
The trigger (a Jenkins or plugin update) is not necessarily the underlying cause of the DEBUG logs.
When this problem is triggered, there may be multiple causes, which makes this problem very difficult to troubleshoot.
The Dormant Problem
In my case, the underlying cause of the DEBUG logging was that I had cobertura-2.1.1.jar in my test dependencies, which contains a logback.xml file and also brings logback-classic.jar in as a dependency (widely regarded as a mistake, see Issue 2, Issue 14, Issue 36). The logback.xml file, when found in the classpath, overrides any other logback settings in Jenkins (and the project being built). However, since logback was not the logging framework selected by Apache Commons Logging (JCL), this log setting had never been triggered.
The Trigger
Upgrading the Artifactory plugin from 2.14.0 to 2.15.0 switched its logging from: commons-logging-1.1.1.jar (log4j-1.2.17.jar) to: jcl-over-slf4j-1.7.25.jar (slf4j-api-1.7.25.jar). FYI, log4j 1.x uses a default root logging level of DEBUG, while log4j 2.x uses a global logging level of ERROR, which may be an entirely different source of DEBUG logging (but not in my case). My build environment (ant) was supplying log4j 2.10.0 and logback on the classpath, which served only to confound my testing by producing inconsistent results depending on which plugins were running within the build process.
When using Artifactory plugin v2.15.0+, the logging framework switches to logback, which gives the logback.xml file in cobertura-2.1.1.jar permission to set the root log level to DEBUG, forcing all of the subsequent parts of the build process to record at the DEBUG level. This includes wire-logging for Apache Commons HttpClient, which produces http-outgoing-0 (serialized hexadecimal and interleaved Base64 encoded content from every HTTP/S message - as you show in your question). Even for a small project, recording a single PUT of a JAR file in this way will increase both the build time and the size of your build logs by several orders of magnitude (this is what I was experiencing in my build environment), which can easily cripple your entire Jenkins server. This is a huge problem, and as you can see from the Cobertura GitHub issues above, even though it is an easy fix, no steps have been taken to produce a fixed version in four years.
The Fix
To fix this, I had to make several changes on my Jenkins server:
Replace logback-classic.jar and logback-core.jar with slf4j-simple-1.7.26.jar in my .ant/lib folder (this is the classpath that Ant uses when building and testing my projects). This change prevents the use of logback at all in Ant (therefore any logback.xml file in the classpath becomes irrelevant), while still allowing your build to perform logging over the SLF4J API (via slf4j-simple).
Remove any dependencies on redundant logging versions (e.g., don't include both commons-logging-1.1.1 and commons-logging-1.2 in the classpath). This is especially important if using log4j, where version 1.1 defaulted to DEBUG, and version 1.2 defaulted to ERROR. You never know which underlying framework JCL will choose, so you want to give it as few options as possible.
Finally, in order for the test environment to match the Ant environment, I adjusted the dependencies of all of my projects to specifically exclude logback-classic (I use Ivy for dependency resolution, so maven or gradle will have a different syntax):
<dependency org="net.sourceforge.cobertura" name="cobertura" rev="latest.release" conf="test->default">
<exclude org="org.apache.ant" />
<exclude name="jaxen" />
<exclude name="jetty" />
<exclude name="jetty-util" />
<exclude name="servlet-api-2.5" />
<exclude name="logback-classic" /> <!-- IMPORTANT -->
</dependency>
For reference, my broken .ant/lib folder contained these logging-related jar files (2 possible sources of DEBUG logs):
commons-logging-1.1.1.jar (redundant JCL version, not certain which was used)
commons-logging-1.2.jar
slf4j-api-1.7.21.jar (logging framework used by new artifactory plugin)
logback-classic-1.0.13.jar (logging framework included from cobertura-2.1.1)
logback-core-1.0.13.jar
while my fixed .ant/lib folder contains the following logging jars:
commons-logging-1.2.jar (now the only available JCL version)
slf4j-api-1.7.26.jar (now the only available logging framework)
slf4j-simple-1.7.26.jar (now the only SLF4J implementation)
In my fixed Ant classpath, commons-logging-1.2 can only select the SLF4J API (or JUL), and only a single SLF4J implementation is available (slf4j-simple).
TL;DR
For three years, Cobertura 2.1.1 was telling logback to "DEBUG All the Things!", but nobody was listening until a new version of the Artifactory plugin changed the JCL version and brought along an SLF4J implementation that allowed logback to be selected as the "best available" logging framework. When the JCL was introduced to logback, logback took Cobertura's advice and threw a party in my build logs. This can be prevented by removing logback from the environment and supplying a well-behaved logging framework for the JCL and SLF4J API (such as slf4j-simple).
We upgraded to Sonar 5.2. But now, the task to process the sonar report fails:
2015.12.21 16:08:20 ERROR [o.s.s.c.t.CeWorkerRunnableImpl] Failed to execute task AVHFFR9SqYJURQAYr8yb
java.lang.IllegalArgumentException: There's no changeset on line 59
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:125) ~[guava-17.0.jar:na]
at org.sonar.server.computation.scm.ScmInfoImpl.getChangesetForLine(ScmInfoImpl.java:64) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.scm.DbScmInfo.getChangesetForLine(DbScmInfo.java:69) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.step.NewCoverageMeasuresStep$NewCoverageCounter.initialize(NewCoverageMeasuresStep.java:391) ~[so
If I uninstall the Cobertura Plugin which has version 1.6.3, then the report process works fine. But that's no solution for me because I need these reports. Did anybody succeed to solve this error in another way?
regards
Two thoughts:
1) Your issue seems related to this discussion on SonarQube's group. Check if you have such line number="0" in your cobertura.xml file. Unfortunately the fix is planned for SonarQube 5.4 (i.e. 04/Mar/16.)
2) Depending on your exact needs related to Cobertura reports generation and if you're using Maven, you can try to use QualInsight Maven Cobertura plugin to generate your Cobertura reports. This plugin provides the qualinsight-mojo-cobertura-core mojo, an alternative to the cobertura-maven-plugin mojo you're probably using if your build is Maven based. QualInsight Maven Cobertura plugin generates separate reports for UTs, ITs, and combined Overall Test coverage. It generates standard cobertura.xml reports, but also is able to convert them to SonarQube Generic Test Coverage plugin format.
Maybe generated reports by qualinsight-mojo-cobertura-core won't contain data causing issues + maybe using SonarQube's Generic Coverage plugin instead of SonarQube's Cobertura plugin won't cause the exception you get (it was released 9 days ago and tested towards SQ 5.2, while the Cobertura plugin was last released in September 2014)
If want to give it a try and need help / have questions with this solution, just ask (I'm the developer QualInsight Maven Cobertura plugin.)
Regards,
I have couple of non mavenized Grails Project (2.2.1 and 2.3.5 versions). I can generate Unit test results (spock test) in XML format.
But these results are not getting published in SonarQube 4.4 version. with Groovy 1.0.1 plugin. Sonar can publish the coverage report.
Below are the sonar properties.
sonar.projectVersion=1.0
sonar.sources=grails-app,src
sonar.tests=test\unit
sonar.language=grvy
sonar.junit.reportsPath=\target\test-reports
I have tried all combination of (relative / absolute) path for reportsPath and tests.
On checking the logs, I dont see Surefire Senor being executed at all. There is a similar issue in the tracker,
http://jira.codehaus.org/browse/SONARGROOV-2?jql=project%20%3D%20SONARGROOV%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Major%20ORDER%20BY%20key%20DESC
But in this scenario, surefire sensor at least gets called /executed but with error.
Ok. I went past this issue after removing sonar.language=grvy property. In this case source files are both in Java and groovy language.
Sonar itself picked the language and surefire sensor did get executed with the 'Resource not found; error as mentioned in the above JIRA issue.
I am wondering if this issue is because of multi-language project.
I'm trying to optimize my build process (in development) in term of time to build the whole tree of maven multi-module project. Some of the POM are actually aggregation of sources/libraries that rarelly (and typically) never change. So specific sub-questions are
Is it possible to somehow configure maven to not build pom if there are no changes in sources specified in POM:project/build/sourceDirectory attribute?
Or is it possible to (at least) conditionally disable maven-bundle-plugin? - it takes most of the time.
Google could not find anything relevant Q#1. Typical solution does not work for #2 - when i try to specify 'executions' for maven-bundle-plugin (like this)
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>${maven-bundle-plugin.version}</version>
<extensions>true</extensions>
<executions>
<execution>
<id>osgi-bundle</id>
<phase>bundle</phase>
<goals>
<goal>bundle</goal>
</goals>
i receive this error in output
[bundle:bundle]
Bundle artifact-id:bundle-id:bundle:0.1.0-SNAPSHOT : The JAR is empty: dot
Error(s) found in bundle configuration
Any help is appreciated. I'm aware about following:
* Disable a Maven plugin defined in a parent POM
(maven-bundle-plugin can't work with 'executions' tag)
* Skip execution of a maven plugin if a file does not exist (maven-bundle-plugin does not have skip confiuration option)
* How to skip lifecycle phase in multi maven module (the same as previous)
* If entire maven-bundle-plugin is moved into profile, maven does not recognize packaging=bundle.
Finally I have to admit that (C) Eugene Kuleshov - "Maven generally don't track sources/changes, so it is always a full build."
But, returning back to Java after 5+ on .NET and 5+ years erlier on C++, it looks weird for me that such a common feature like incremental build is not support by widely used tool having a history of 10+ years. So I could not spend my time on waiting to rebuild each and every unchanged module in my multi-module project and decided to make customized version of Maven 3.0.4 :)
Feel free to grab it here http://code.google.com/p/maven-onchange-activator/, try and report issues.
Maven generally don't track sources/changes, so it is always a full build. However to disable any plugin you could move it into profile and then enable/disable the whole profile, e.g. either conditionally or from the command line.
You should check things like
mvn -am
in relationship with
mvn -pl ...
so doing a build like:
mvn -am -pl SubModule clean package
will build only those modules which have been changed and which needed to be built as a result of a dependency to the change module.
I would suggest switching to Gradle.
Gradle has such support out of the box (no configuration needed) and conversion from Maven should be easy.
Does anybody know of any reason why some of my projects are marked as SKIPPED at the end of a successful maven build?
please note that the 'skip chain' always starts with my web project which includes the following features:
jspc-maven-plugin
war plugin with overlay
maven-dependency-plugin
It could be due to OutOfMemoryError's inside Maven. We had similar problem with Maven skipping half of the modules. Increasing memory for Maven process itself solved the issue. I don't know if it is specific to some particular plugin behaving bad or to the Maven core.