Maven Plugin JaCoCo Fehler

Question

ich das Maven Plugin JaCoCo konfiguriert haben wie in meiner pom.xml Datei folgt:

<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> 

Ich verwende Windows 7 und die Apache-Maven-3.0.4-Plugin. Wenn ich mvn -P jacoco4 install entweder von einem Cygwin-Terminal oder von einem Eingabeaufforderungsterminal eintippe, lädt Maven das JaCoCo-Plugin herunter und führt es aus, aber dann scheint die jacoco.exec-Datei nicht erstellt worden zu sein. Im Folgenden finden Sie die Fehlermeldung:

[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) 

Diese Fehlermeldung erscheint, ob ich schließe die destfile und datafile Planer in der Konfiguration des Plugins:

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

Kann mir bitte jemand sagen, was ich bin falsch machen?

Answer 1

Ich benutze Konfiguration:

<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> 

Update: Konfiguration erzeugt durch Sonar (Sonar-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> 

Ein Problem - wie definieren "jacocoagent3671192291664069011.jar" für jeden Build. Es sollte sein in:

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

Answer 2

Ich hatte die gleichen Probleme mit Jacoco und Maven. Es war verwandt mit einem Elternteil pom überschreiben die Konfiguration von todsicheren. In diesem Fall verwendete das Plugin nicht das Argument (für das Argument jvm), das den Agenten definierte.

Die Lösung war die "argLine" Konfigurationselement zurück zu setzen

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

Voll Plugin conf sieht aus wie

<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> 

es über diese

Answer 3

ich sehr nützlich sein, Hoffnung werde auch kam Problem: JaCoCo erzeugt keine Ausgangsdatei 'jacoco.exec', was bedeutet, dass keine Coverage-Analyse stattfindet.

In meinem Fall war es auch wegen der Verwendung einer benutzerdefinierten argLine im Maven Surefire Plugin, die das JaCoCo Maven Plugin argLine überging, was dazu führte, dass JaCoCo nicht ausgeführt wurde.

dies zu beheben ich die JaCoCo optionalen Parameter „PROPERTY“ verwendet, um seine argLine auf eine Maven Eigenschaft zu exportieren und zu enthalten, dass in der todsicheren 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> 

jedoch dies ein Problem verursacht, wenn einzelne Tests durchgeführt wurden Netbeans. Da das JaCoCo-Plugin in diesem Szenario nicht ausgeführt wurde, wurde die Variable "jacoco.agent.argLine" nicht initialisiert und Surefire ist fehlgeschlagen, bevor Tests ausgeführt wurden.

Das Hinzufügen einer leeren Eigenschaft "jacoco.agent.argLine" zum Pom löste das Problem, wenn einzelne Tests ausgeführt wurden. Dadurch wurde jedoch auch verhindert, dass JaCoCo seine argLine beim Ausführen exportierte, wodurch JaCoCo effektiv deaktiviert wurde.

Der letzte Teil der Lösung, die ich verwendet habe, war ein Profil hinzuzufügen, die die leere Eigenschaft erstellt und aktiviert nur dann, wenn ein einzelner Test angegeben ist:

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

Answer 4

OK Ich glaube, ich herausgefunden, was es geht voran.

standardmäßig die jacoco Plugin „läuft“ vor der Testphase (in der Regel läuft es prepare-agent Ziel während der initialize Phase des Lebenszyklus), und wenn es läuft, setzt sich nur eine Maven Eigenschaft namens „argLine“, um so etwas wie -javaagent=jacoco.jar

ex:

[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

standardmäßig maven-todsichere-Plugin im Grunde "wird vorangestellt" Unterkunft (wenn es etwas gesetzt ist) zu seinem gegabelten java Testprozesse, so dass sie die Waren erhalten. Ex: java ${argLine ends up here}> -jar /xxx/surefirebooter3741906822495182152.jar

Typisch (ohne jacoco), wenn Sie wollen auch noch etwas anderes von Ihrer eigenen ergänzen, dass argLine (zum Beispiel -Xmx1G oder dergleichen), Sie setzen es gerade in der todsicheren Konfiguration, wie

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

wenn Sie jedoch jacoco verwenden, können Sie es auf dem normalen Weg nicht tun Sie es tun, indem eine globale Eigenschaft festlegen, this way statt:

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

wenn Sie Setzen Sie die <configuration><argLine> dann im Grunde überschreibt es die Systemeigenschaft, so dass Jacoco-Argumente nicht an den untergeordneten Prozess weitergegeben werden. Deshalb verwenden Sie stattdessen die Property Way. Wenn Sie eine Eigenschaft argLine angeben, fügt jacoco einfach seine Parameter zu dem hinzu, was Sie angeben, dann wird todsichere es verwenden.

Wie auch immer, wenn Ihre Eltern POM hat bereits setzen Sie die <configuration><argLine> des Plugins auf etwas? Oder wenn du es selbst einstellst? Es wird im Grunde diesen Wert anstelle der Eigenschaft verwenden, die jacoco setzt (Sie haben eine manuelle Überschreibung angegeben).

Wenn Sie selbst <configuration><argLine> angeben, können Sie diese argLine in eine Eigenschaft ändern (siehe oben) und entfernen Sie die <configuration><argLine> und es sollte funktionieren. Wenn Sie das übergeordnete Element nicht steuern können und das übergeordnete Element etwas für argline angibt, müssen Sie die Route <configuration><argLine>${argLine} -Xmx1G</argLine> aufrufen. Dadurch wird es angewiesen, zu ignorieren, wofür der Elternteil diesen Wert gesetzt hat, und stattdessen argLine zu verwenden (dasjenige, das jacoco für dich setzt). (Es ist mir unklar, ob es eine einfache Möglichkeit gibt, den Wert, den der Elternteil für diesen Wert hat, zu "addieren", wenn jemand weiß, wie es sich hier frei äußern kann).

Aber was, wenn jacoco nicht für irgendein Ziel oder irgendein Profil läuft? Dann wird die Variable ${argLine} wird nie gesetzt, und Sie können wie folgt in einen Fehler laufen:

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}' ...

Nun stellt sich heraus, dass jacoco nur „ergänzt“ auf die Eigenschaft mit dem Namen argLine, wenn es ausgeführt wird. So können Sie problemlos einen <properties><argLine></argLine></properties> zu Ihrem Pom hinzufügen (es sei denn, Sie haben dies bereits im übergeordneten Pom festgelegt, dann müssen Sie nichts hinzufügen). Wenn jacoco jemals aufgerufen wird, fügt es hinzu. Ist dies nicht der Fall, wird eine leere Zeichenfolge festgelegt, die in Ordnung ist. Es ist auch nicht klar, ob es eine Möglichkeit gibt, den Wert des Parents für eine Eigenschaft zu "hinzufügen", also erbt sie es, wenn Sie wissen, dass es existiert, oder Sie geben es als leer an.

So, am Ende für mich, da meinen Upstream (nicht zugänglich) Eltern pom erklärte es wie

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

ich gezwungen war, im Grunde diesem Weg zu folgen, da sie (die in einem bereits festgelegt wurden meiner Kontrolle) Eltern pom, so:

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