2012-09-04 76 views
16

He configurado el plugin Maven JaCoCo de la siguiente manera en mi pom.xml:Maven JaCoCo error plug-in

<properties> 
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
    <jacoco.version>0.5.9.201207300726</jacoco.version> 
</properties> 

<profiles> 
    <profile> 
     <id>jacoco4</id> 
     <build> 
      <plugins> 
       <plugin> 
        <groupId>org.jacoco</groupId> 
        <artifactId>jacoco-maven-plugin</artifactId> 
        <version>${jacoco.version}</version> 
        <executions> 
         <execution> 
          <goals> 
           <goal>prepare-agent</goal> 
          </goals> 
          <configuration 
          <destfile>${project.build.directory}/target/jacoco.exec</destfile> 
          <datafile>${project.build.directory}/target/jacoco.exec</datafile> 
           <output>file</output> 
           <append>true</append> 
          </configuration> 
         </execution> 
         <execution> 
          <id>report</id> 
          <phase>prepare-package</phase> 
          <goals> 
           <goal>report</goal> 
          </goals> 
         </execution> 
        </executions> 
       </plugin> 
      </plugins> 
     </build> 
    </profile> 
</profiles> 

estoy usando Windows 7 y el plugin apache-maven-3.0.4. Cuando escribo mvn -P jacoco4 install, ya sea desde un terminal cygwin o desde un terminal de símbolo del sistema, Maven descarga y ejecuta el complemento JaCoCo, pero entonces el archivo jacoco.exec no parece haber sido creado. A continuación se muestra el mensaje de error:

[ERROR] Unable to read execution data file C:\Users\brownru\workspace64new\vps9\vps-fileserver\target\jacoco.exec: C:\Users\brownru\workspace64new\vps9\vps-fileserver\target\jacoco.exec (The system cannot find the file specified) 
java.io.FileNotFoundException: C:\Users\brownru\workspace64new\vps9\vps-fileserver\target\jacoco.exec (The system cannot find the file specified) 
     at java.io.FileInputStream.open(Native Method) 
     at java.io.FileInputStream.<init>(FileInputStream.java:120) 
     at org.jacoco.maven.ReportMojo.loadExecutionData(ReportMojo.java:251) 
     at org.jacoco.maven.ReportMojo.executeReport(ReportMojo.java:228) 
     at org.jacoco.maven.ReportMojo.execute(ReportMojo.java:217) 
     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) 
     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 
     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) 
     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) 
     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) 
     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) 
     at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) 
     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) 
     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) 
     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) 
     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) 
     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) 
     at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) 

Este mensaje de error aparece si o no incluyo los destfiledatafile y especificadores en la configuración del plugin:

<destfile>${project.build.directory}/target/jacoco.exec</destfile> 
<datafile>${project.build.directory}/target/jacoco.exec</datafile> 

¿Puede alguien decirme lo que estoy haciendo mal?

Respuesta

0

utilizo configuración:

<plugin> 
     <groupId>org.jacoco</groupId> 
     <artifactId>jacoco-maven-plugin</artifactId> 
     <version>${jacoco.version}</version> 
      <configuration> 
        <skip>${skipTests}</skip> 
      </configuration> 
      <executions> 
        <execution> 
           <id>jacoco-initialize</id> 
           <phase>initialize</phase> 
           <goals> 
            <goal>prepare-agent</goal> 
           </goals> 
          </execution> 
          <execution> 
           <id>jacoco-site</id> 
           <phase>package</phase> 
           <goals> 
            <goal>report</goal> 
           </goals> 
          </execution> 
      </executions> 
     </plugin> 

Actualización: configuración generada por el sonar (sonar de pom.xml):

<plugin> 
     <artifactId>maven-surefire-plugin</artifactId> 
     <version>2.12</version> 
     <executions> 
      <execution> 
      <id>default-test</id> 
      <phase>test</phase> 
      <goals> 
       <goal>test</goal> 
      </goals> 
      <configuration> 
       <excludedGroups>server,ignore,integration</excludedGroups> 
      </configuration> 
      </execution> 
     </executions> 
     <configuration> 
      <excludedGroups>server,ignore,integration</excludedGroups> 
      <argLine>-javaagent:/tmp/jacocoagent3671192291664069011.jar=destfile=target/jacoco.exec,excludes=*_javassist_*</argLine> 
      <testFailureIgnore>true</testFailureIgnore> 
     </configuration> 
     </plugin> 

Uno de los problemas - ¿Cómo definir "jacocoagent3671192291664069011.jar" para cada construcción. Debe estar en:

$M2_HOME/repository/org/jacoco/org.jacoco.agent/${jacoco.version}/org.jacoco.agent-${jacoco.version}-runtime.jar 
+0

@kirigiri ¿Has probado la configuración de mi? –

+0

Gracias por su respuesta, que no vi hasta hoy. Intenté su configuración, con la excepción de $ {skipTests}, pero su configuración no resuelve el problema. ¿Tienes alguna otra idea? – kirigiri

+0

Tienes razón. Acabo de copiar de mi proyecto (padre pom). Las pruebas se omiten para algunos módulos. Yo uso jenkins con sonar (y jacoco). Allí no es necesario ejecutar jacoco manualmente. –

21

Tuve el mismo problema con jacoco y maven. Se relacionó con un pom padre sobrescribiendo la configuración de surefire. En este caso, ese complemento no utilizó el argumento (para el argumento jvm) que define el agente.

La solución fue poner el elemento de configuración "argLine" volver

<plugin> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <configuration> 
    <argLine>${argLine}</argLine> 
    </configuration> 
</plugin> 

conf complemento completo parece

<plugin> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <configuration> 
    <skip>true</skip> 
    </configuration> 
    <executions> 
    <execution> 
     <id>unit-test</id> 
     <phase>test</phase> 
     <goals> 
     <goal>test</goal> 
     </goals> 
     <configuration> 
     <skip>${maven.test.skip}</skip> 
     <argLine>${argLine}</argLine> 
     <excludes> 
      <exclude>**/*IntegrationTest.java</exclude> 
     </excludes> 
     </configuration> 
    </execution> 
    <execution> 
     <id>integration-test</id> 
     <phase>integration-test</phase> 
     <goals> 
     <goal>test</goal> 
     </goals> 
     <configuration> 
     <skip>${skipITs}</skip> 
     <argLine>${argLine}</argLine> 
     <includes> 
      <include>**/*IntegrationTest.java</include> 
     </includes> 
     </configuration> 
    </execution> 
    </executions> 
</plugin> 
<plugin> 
    <groupId>org.jacoco</groupId> 
    <artifactId>jacoco-maven-plugin</artifactId> 
    <version>0.5.10.201208310627</version> 
    <configuration> 
     <skip>${maven.test.skip}</skip> 
     <destFile>${basedir}/target/coverage-reports/jacoco-unit.exec</destFile> 
     <dataFile>${basedir}/target/coverage-reports/jacoco-unit.exec</dataFile> 
     <output>file</output> 
     <append>true</append> 
    </configuration> 
    <executions> 
     <execution> 
      <id>jacoco-initialize</id> 
      <goals> 
       <goal>prepare-agent</goal> 
      </goals> 
     </execution> 
     <execution> 
      <id>jacoco-site</id> 
      <phase>verify</phase> 
      <goals> 
       <goal>report</goal> 
      </goals> 
     </execution> 
    </executions> 
</plugin> 

espero que sea útil

+3

agregando el $ {argLine} funcionó para mí. Solo asegúrate de agregarlo al plugin de compilación y no al plugin de informes (como lo que probé primero). Gracias. –

+0

Muchas gracias Cómo llevarlo al sitio, actualmente es un sitio separado –

+0

Gracias por esto. Supongo que hay que tener cuidado al anular la configuración predeterminada de un complemento maven. – dkateros

7

También me encontré con este problema: JaCoCo no produce un archivo de salida 'jacoco.exec', lo que significa que no se produce ningún análisis de cobertura de código.

En mi caso, también se debió al uso de una argLine personalizada en el Plugin Maven Surefire, que anuló el complemento JaCoCo Maven argLine, haciendo que JaCoCo no se ejecutara.

Para solucionar esto he utilizado el parámetro opcional JaCoCo "nombrePropiedad" para exportar su argLine a una propiedad Maven e incluía que en el éxito seguro argLine:

<plugin> 
    <groupId>org.jacoco</groupId> 
    <artifactId>jacoco-maven-plugin</artifactId> 
    <configuration> 
     <propertyName>jacoco.agent.argLine</propertyName> 
    </configuration> 
    ...    
</plugin> 

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <version>2.10</version> 
    <configuration> 
     <argLine>-XX:-UseSplitVerifier ${jacoco.agent.argLine}</argLine> 
    </configuration> 
</plugin> 

Sin embargo, esto causó un problema cuando las pruebas individuales se llevaron a cabo en Netbeans. Debido a que el complemento JaCoCo no se ejecutó en este escenario, la variable "jacoco.agent.argLine" no se inicializó y Surefire falló antes de ejecutar cualquier prueba.

Agregar una propiedad en blanco "jacoco.agent.argLine" al pom resolvió el problema al ejecutar pruebas individuales, pero esto también impidió que JaCoCo exportara su argLine cuando se estaba ejecutando, desactivando efectivamente JaCoCo.

La parte final de la solución que he utilizado fue la de añadir un perfil que crea la propiedad en blanco, y se activa sólo cuando se especifica una sola prueba:

<profiles> 
    <profile> 
     <activation>     
      <property> 
       <name>test</name>  
      </property> 
     </activation> 
     <properties> 
      <jacoco.agent.argLine></jacoco.agent.argLine> 
     </properties> 
    </profile> 
</profiles> 
+0

¡Gracias! Lo último que busqué sobre el perfil de prueba fue lo que estaba buscando. – nzhenry

13

bien creo que me di cuenta de lo está pasando.

Por defecto, el jacoco plug-in "corre" antes de la fase de prueba (por lo general se ejecuta el objetivo prepare-agent durante la fase de initialize ciclo de vida), y cuando se acaba, sólo se establece una propiedad experto llamado "argLine" a algo como -javaagent=jacoco.jar

ejemplo:

[INFO] argLine set to -javaagent:/usernamed/.m2/repository/org/jacoco/org.jacoco.agent/ 0.5.6.2012/org.jacoco.agent-0.5.6.2012-runtime.jar=destfile=/path/to/target/jacoco.exec

Por defecto, experto-segura-plugin básicamente "antepone" esta propiedad (si está configurado para nada) a sus procesos de prueba de java bifurcadas, por lo que reciben la mercancía. Ej: java ${argLine ends up here}> -jar /xxx/surefirebooter3741906822495182152.jar

Normalmente (sin jacoco), si quieres también añadir algo más de su preferencia para que argLine (por ejemplo, -Xmx1G o similar), que acaba de establecer en la configuración segura, como

<build> 
    <plugins> 
    <plugin> 
     <artifactId>maven-surefire-plugin</artifactId> 
     <configuration> 
      <argLine>-Xmx1G</argLine> 
      </configuration> 
    </plugin> 

sin embargo, si usted está utilizando jacoco, no puede hacerlo de la manera normal, lo hace mediante el establecimiento de una propiedad global, en lugar this way:

<properties> 
    <argLine>-Xmx1G</argLine> 
    </properties> 

Si establece el <configuration><argLine> y básicamente anula la propiedad del sistema, por lo que los argumentos de jacoco no se pasan al proceso secundario. Entonces, es por eso que usas el modo propiedad. Si especificas una propiedad argLine, entonces jacoco solo agregará sus parámetros a lo que especifiques, luego surefire lo usará.

Sin embargo, lo que si su padre tiene pom ya establecido del plugin <configuration><argLine> a algo? ¿O si tú mismo lo estás configurando? Básicamente usará ese valor en lugar de la propiedad que está configurando jacoco (ha especificado una anulación manual).

Si está especificando <configuration><argLine> usted mismo, puede cambiar esa argLine en una propiedad (ver arriba), y eliminar el <configuration><argLine> y debería funcionar. Si no puede controlar al padre y el padre especifica algo para el argline, entonces deberá ir a la ruta <configuration><argLine>${argLine} -Xmx1G</argLine>. Esto es para indicarle que ignore lo que sea que el padre establezca este valor, y use argLine en su lugar (el que jacoco establece para usted). (No me queda claro si hay una manera fácil de "agregar" el valor que tiene el pom padre para este valor, si alguien sabe cómo no dude en comentar aquí).

¿Pero y si jacoco no funciona para algún objetivo, o algún perfil? A continuación, la variable ${argLine} nunca se consigue el sistema, y ​​se puede ejecutar en un error como este:

Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.14:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? [ERROR] Command was/bin/sh -c cd ...java '${argLine}' ...

Pues resulta que jacoco única "añade" a la propiedad denominada argLine, cuando se ejecuta. De modo que puede agregar de manera segura un <properties><argLine></argLine></properties> a su pom (a menos que ya tenga ese conjunto en el pom principal, entonces no necesita agregar nada). Si jacoco alguna vez se invoca, se agrega a él. Si no, se establece en una cadena vacía, lo cual está bien. Tampoco está claro si hay una forma de "agregar" valor al padre de una propiedad, por lo que puede heredarlo, si sabe que existe, o especificarlo como vacío.

Así, al final para mí, ya que mi aguas arriba (inaccesibles) pom padres declarado como

<configuration><argList>${argList}</argList></configuration>

me vi obligado a seguir básicamente esa ruta, ya que se estableció ya en un (a cabo de mi control) pom padres, así:

<configuration><argList>${argList} -Xmx1G</argList></configuration>

Cuestiones relacionadas