Maven - Tweaking the phase where to run a plugin declared in the reporting section
Asked Answered
D

2

7

I am trying to tweak the phase when a maven plugin execution will run in maven-2.

My specific issue is with attempting to run the cobertura:instrument step bound to the lifecycle phase process-test-classes, so that it doesn't conflict with other plugins that use aspectj (and remove instrumentation code, thus generating a coverage report of 0%). But my question is more generic.

Within the deafault lifecycle, I have managed to do that by adding an executions section in my plugin declaration:

<build>
    <plugins>
        ...
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>cobertura-maven-plugin</artifactId>
            <version>2.4</version>
            <executions>
                <execution>
                    <id>instrument-late</id>
                    <phase>process-test-classes</phase>
                    <goals>
                        <goal>instrument</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        ...

This way, when I run mvn test everything works fine, cobertura:instrument is run at the phase I want, classes get instrumented, tests run with instrumented classes, etc. This is summarized output:

[INFO] [clean:clean {execution: default-clean}]
[INFO] [buildnumber:create {execution: default}]
[INFO] [native2ascii:native2ascii {execution: native2ascii-utf8}]
[INFO] [native2ascii:native2ascii {execution: native2ascii-8859_1}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] [compiler:compile {execution: default-compile}]
[INFO] [jar:jar {execution: lib}]
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Preparing hibernate3:hbm2ddl
[WARNING] Removing: hbm2ddl from forked lifecycle, to prevent recursive invocation.
[INFO] [buildnumber:create {execution: default}]
[INFO] Change the default 'svn' provider implementation to 'javasvn'.
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 2082 at timestamp: 1299861835678
[INFO] Storing buildScmBranch: trunk
[INFO] [native2ascii:native2ascii {execution: native2ascii-utf8}]
[INFO] [native2ascii:native2ascii {execution: native2ascii-8859_1}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] [hibernate3:hbm2ddl {execution: default}]
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] [jar:test-jar {execution: tests}]
[INFO] [dbunit:operation {execution: test-compile}]
[INFO] [cobertura:instrument {execution: instrument-late}]
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory: /home/carles/dev/ism4web/portasigma/portasigma-web/target/surefire-reports

...

Results :

Tests run: 62, Failures: 0, Errors: 0, Skipped: 0

Flushing results...
Flushing results done
Cobertura: Loaded information on 74 classes.
Cobertura: Saved information on 74 classes.
[INFO] [dbunit:operation {execution: test}]

However, when I do mvn site I seem to have no control over the execution phase for the plugin. My reporting section contains:

<reporting>
    <plugins>
        ...
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>cobertura-maven-plugin</artifactId>
            <version>2.4</version>
        </plugin>

And the output of mvn site (summarized) says:

[INFO] [clean:clean {execution: default-clean}]
[INFO] [buildnumber:create {execution: default}]
[INFO] [native2ascii:native2ascii {execution: native2ascii-utf8}]
[INFO] [native2ascii:native2ascii {execution: native2ascii-8859_1}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] [compiler:compile {execution: default-compile}]
[INFO] [jar:jar {execution: lib}]
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] [hibernate3:hbm2ddl {execution: default}]
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] [jar:test-jar {execution: tests}]
[INFO] [dbunit:operation {execution: test-compile}]
[INFO] [cobertura:instrument {execution: instrument-late}]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Unable to prepare instrumentation directory.
Embedded error: source and destination are the same directory.

Instrument is called twice, one at the (I presume) default phase defined by the plugin, and another one at my redefined phase. I guess that comes from the plugin running during as part of the site lifecycle.

THE QUESTION: I haven't found how to tweak the plugin execution within the reporting section / site lifecycle. Any hints?

Dereliction answered 11/3, 2011 at 17:5 Comment(2)
I'm assuming you're using maven-2, are you having the same issue with maven-3?Euchre
You're assuming right. I haven't migrated to maven-3. I solved the specific issue of generating coverage reports in a different way - namely by using the cobertura-it maven plugin, that gives a finer grained control for its execution steps.Underachieve
R
1

I'm guessing here but I think what is happening is that because the cobertura goal runs in its own lifecycle the instrumentation step is called twice, once from the maven lifecycle and once from the cobertura lifecycle.

Runoff answered 17/2, 2012 at 9:54 Comment(0)
P
0

After number of tries with Cobertura I switched to JaCoCo - instrumentation on the fly and option of restoring instrumented classes.

Though I have not tried your proposed cobertura-it.

Only config required beside adding the plugin:

<executions>
  <execution>
    <id>jacoco-initialize</id>
    <phase>initialize</phase> <!-- m2e complains if you skip, though mine complains on this either, had to mark it as ignored by m2e, feel free to omit the phase, defaults are fine -->
    <goals>
      <goal>prepare-agent</goal>
    </goals>
  </execution>
  <execution>
    <id>jacoco-site</id>
    <phase>package</phase>
    <goals>
      <goal>report</goal>
    </goals>
  </execution>
</executions>

Additional bonus for me is that I had no longer issues with Java 1.7.

EDIT: changed phase for jacoco-initialize, previous version was wrong: after mvn clean it no longer would create jacoco.exec file thus resulting in no coverage reports.

Polytrophic answered 15/8, 2013 at 9:11 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.