Anomalie SLF4J Cobertura

Votre avis

Nobody voted on this yet  You need to enable JavaScript to vote

Tweet

Lors de l'analyse automatisée par Jenkins d'un projet Maven, avec publication des résultats sous SonarQube en version 4.2, la publication de la couverture de test ne produisait aucun résultat.

Cet article présente l'anomalie rencontrée ainsi que la solution mise en place.

Description

L'analyse Cobertura doit produire le fichier target/site/cobertura/coverage.xml, si configuré pour produire un rapport au format XML, afin de produire des métriques sur la couverture des tests. Lors de la mise à jour de la version 4.2, ce fichier ne représentait aucune information de couverture.

La trace d'exécution de Jenkins présentait l'erreur suivante.

Exception in thread "Thread-0" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
	at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:115)
	at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439)
	at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:395)
	at ch.qos.logback.classic.Logger.info(Logger.java:599)
	at net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.loadCoverageData(CoverageDataFileHandler.java:86)
	at net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.loadCoverageData(CoverageDataFileHandler.java:62)
	at net.sourceforge.cobertura.coveragedata.ProjectData.loadCoverageDataFromDatafile(ProjectData.java:328)
	at net.sourceforge.cobertura.coveragedata.ProjectData.saveGlobalProjectData(ProjectData.java:301)
	at net.sourceforge.cobertura.coveragedata.SaveTimer.run(SaveTimer.java:33)
	at java.lang.Thread.run(Thread.java:745)

Une version de slf4j semble être déjà chargée lors de l'exécution, et non compatible avec le plugin Cobertura. Il faut donc chercher dans le projet si slf4j est une dépendance. La commande dependency:tree va permettre d'effectuer cette analyse, par exemple sur l'étude de TIKA 1.1.

#mvn dependency:tree -Dincludes=*slf4j*
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Tika Study 1.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ tika ---
[INFO] fr.ejn.tutorial:tika:jar:1.1
[INFO] \- org.apache.tika:tika-parsers:jar:1.1:compile
[INFO]    \- edu.ucar:netcdf:jar:4.2-min:compile
[INFO]       \- org.slf4j:slf4j-api:jar:1.5.6:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.658 s
[INFO] Finished at: 2015-08-27T22:23:02+02:00
[INFO] Final Memory: 24M/992M
[INFO] ------------------------------------------------------------------------

La version 1.5.6, donc utilisé et semble être la cause du conflit.

Résolution

La solution est finalement assez simple. Il faut injecter une version correcte dans le projet. Cependant, il n'est pas envisageable de surcharger la version utilisée par le framework TIKA. La surcharge est donc réalisée uniquement dans le périmètre des tests unitaires. Ainsi, la version correcte sera disponible lors de l'analyse, mais ne sera pas exploitée lors de la génération du paquet.

La dépendance suivate est injectée dans le fichier pom.xml du projet.

	<!-- Add version slf4j that match the one in Sonar analysis. -->
	<dependency>
		<groupId>org.slf4j</groupId>
		<artifactId>slf4j-api</artifactId>
		<version>1.6.6</version>
		<scope>provided</scope>
	</dependency>

L'ajout de la valeur provided dans la configuration scope, permet de ne rendre disponible cette version que pour les test.

L'nalayse produit alors des résultats sur la couverture de tests.