Looks like I was able to isolate the problem:

*[INFO] configuring report plugin
org.apache.maven.plugins:maven-surefire-report-plugin:2.19.1*

*[INFO] preparing 'report' report requires '[surefire]test' forked phase
execution*

[INFO]

[INFO] >>> maven-surefire-report-plugin:2.19.1:report > [surefire]test @
PROJECT >>>

[INFO]

[INFO] --- xmlbeans-maven-plugin:2.3.3:xmlbeans (default) @ PROJECT ---

[INFO] All schema objects are up to date.

[INFO]

[INFO] --- maven-resources-plugin:2.7:resources (default-resources)
@ PROJECT ---

[INFO] Using 'utf-8' encoding to copy filtered resources.

[INFO] Copying 7 resources

[INFO] Copying 103 resources

[INFO] Copying 103 resources

[INFO]

[INFO] --- jrebel-maven-plugin:1.1.5:generate (generate-rebel-xml)
@ PROJECT ---

[INFO] Processing PROJECT with packaging jar

[INFO]

[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile)
@ PROJECT ---

[INFO] Changes detected - recompiling the module!

[INFO] Compiling 77 source files to ...


[INFO] ---* jacoco-maven-plugin:0.7.6.201602180812:instrument
(offline-instrument) @ PROJECT* ---

[INFO]

[INFO] --- maven-resources-plugin:2.7:testResources (default-testResources)
@ PROJECT ---

[INFO] Using 'utf-8' encoding to copy filtered resources.

[INFO] Copying 3 resources

[INFO]

[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile)
@ PROJECT ---

[INFO] Nothing to compile - all classes are up to date

[INFO]

[INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ PROJECT ---

[INFO] *Skipping execution of surefire because it has already been run for
this configuration*

[INFO]

[INFO] <<< maven-surefire-report-plugin:2.19.1:report < [surefire]test @
PROJECT <<<


So, surefire-reports reruns surefire:test with all the preparation steps.
Whereas surefire:test detects that it was already ran, jacoco:instrument
does realize that it was already executed. And as the post-processing steps
do not get executed, restore-instrumented-classes is not invoked a second
time. Therefore - after the surefire-report to surefire call - the classes
contain instrumentation data, which then tricks the jacoco report
generation that the Maven Site Plugin performs. I moved the
restore-instrumented-classes invocation from its default phase to the test
phase and this solved the problem. But I assume that this won't work for
users that also use the Failsafe plugins together with Surefire. So, a real
solution IMHO can only be that the jacoco:instrument implementation detects
that it was already executed once, similar to what surefire:test does.


Florian

2016-04-19 18:51 GMT+02:00 Mirko Friedenhagen <mfriedenha...@gmail.com>:

> Hello Florian,
>
> did you put the reporting section into the profile as well? This should
> just work AFAIK.
>
> Regards
> Mirko
> --
> Sent from my mobile
> Am 19.04.2016 13:42 schrieb <fwies...@gmail.com>:
>
>> Hi,
>>
>> In our project we use offline instrumentation as we are doing AspectJ
>> compile-time weaving. The report generated by the Maven report goal is
>> accurate (although we use PowerMockito), but it is currently generated from
>> the Maven default lifecycle, not the site lifecycle:
>>         <profile>
>>             <id>jacoco-coverage</id>
>>             <build>
>>                 <plugins>
>>                     <plugin>
>>                         <groupId>org.jacoco</groupId>
>>                         <artifactId>jacoco-maven-plugin</artifactId>
>>                         <configuration>
>>                             <excludes>
>>                                 <!-- our excludes -->
>>                             </excludes>
>>                         </configuration>
>>                         <executions>
>>                             <execution>
>>                                 <id>offline-instrument</id>
>>                                 <goals>
>>                                     <goal>instrument</goal>
>>                                 </goals>
>>                             </execution>
>>                             <execution>
>>                                 <id>restore-classes</id>
>>                                 <goals>
>>
>> <goal>restore-instrumented-classes</goal>
>>                                 </goals>
>>                             </execution>
>>                             <execution>
>>                                 <id>default-report</id>
>>                                 <goals>
>>                                     <goal>report</goal>
>>                                 </goals>
>>                             </execution>
>>                         </executions>
>>                     </plugin>
>>                     <plugin>
>>                         <artifactId>maven-surefire-plugin</artifactId>
>>                         <configuration>
>>                             <systemPropertyVariables>
>>
>> <jacoco-agent.destfile>target/jacoco.exec</jacoco-agent.destfile>
>>                             </systemPropertyVariables>
>>                         </configuration>
>>                     </plugin>
>>                 </plugins>
>>             </build>
>>         </profile>
>>
>>
>> Now, when I invoke mvn clean install site -P jacoco-coverage, this of
>> course leads to the JaCoCo report not being shown under Project Reports.
>> On the other hand, adding
>>
>>   <reporting>
>>       <plugins>
>>           <plugin>
>>               <groupId>org.jacoco</groupId>
>>               <artifactId>jacoco-maven-plugin</artifactId>
>>           </plugin>
>>       </plugins>
>>   </reporting>
>>
>> leads to JaCoCo attempting another instrumentation of the classes in the
>> site rendering phase, which then fails.
>>
>> Is there a way to tell the jacoco-maven-plugin to not perform a second
>> report generation, if there is already a generated report in the build
>> sequence, so that it only attaches it as site artifact?
>>
>>
>> Thank you!
>> Florian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "JaCoCo and EclEmma Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jacoco+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jacoco/82e705e3-1694-44ec-89f4-2fbdc42c5642%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "JaCoCo and EclEmma Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jacoco/juY3yFMTkVw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jacoco+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jacoco/CAK8jvqxJSdvP0RtuzQiPschUSuMOxqZ-W48CCtYGw8yWJHUEyQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jacoco/CAK8jvqxJSdvP0RtuzQiPschUSuMOxqZ-W48CCtYGw8yWJHUEyQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jacoco+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jacoco/CACgQafMq6vRTbardN0cP3c7_miAXp-in%3DvH0EKdtFN67bhirKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to