Cobertura Plugin And Site Generation

[Lennart Jörelid]

Hello all,

I have come across a rather interesting situation; the Jaxb2-Maven-Plugin is ready for a release sporting - among other things - Java 11 and Http Proxy support.

However, I cannot generate the site due to a cobertura-related error where it seems that the Cobertura-Maven-Plugin by default attempts to instrument the integration tests of the plugin.

This seems to fail, and hence the site cannot be properly generated.

What is the workaround here?

The simplest way to check is to clone the repo at (g...@github.com:mojohaus/jaxb2-maven-plugin.git), build the plugin and build the site.

Building the site is done using:

mvn -Pmojo-release clean deploy

.. which eventually fires the ITs and generates the following (which is only generated by the site plugin; not the building of the plugin iself):

Caused by: java.lang.NoClassDefFoundError: net/sourceforge/cobertura/coveragedata/LightClassmapListener

    at java.lang.Class.getDeclaredMethods0 (Native Method)

    at java.lang.Class.privateGetDeclaredMethods (Class.java:2701)

    at java.lang.Class.getDeclaredMethods (Class.java:1975)

    at com.google.inject.spi.InjectionPoint.getInjectionPoints (InjectionPoint.java:688)

    at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields (InjectionPoint.java:380)

    at com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies (ConstructorBindingImpl.java:164)

    at com.google.inject.internal.InjectorImpl.getInternalDependencies (InjectorImpl.java:613)

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

[Lennart Jörelid]

Hm.

So .. downgrading to Mojo-Parent version 40 implies that a truckload of errors are shown when generating the site; but the build process is not aborted.

Doing the release using the old parent.

Can we get rid of Cobertura in the site, considering that it does not work for Java 8+?

[Jochen Wiedmann]

According to https://github.com/cobertura/cobertura/issues/128, it
helps to add a dependency on net.sourceforge.cobertura:cobertura.

Jochen

> --
> You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.
> To post to this group, send email to mojoha...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/a06d5a26-d73c-4d51-9981-074ba46fa12a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Lennart Jörelid]

Actually, it does not.

The problem is that the IT:s in mojo-parent version 50 are run with Cobertura instrumentation.

The implication of this is that the POM of each IT needs the Cobertura depdendency within the plugin dependencies when running the mvn site goal.

So ... I would really need to programmatically adjust the dependencies of the plugin only when running the ITs of the project itself. 

1. Is there a convenient way to do that using the capabilities of the Maven-Invoker-Plugin?
2. I would like *not* to have to add this dependency to all IT POMs; it has a code smell.
3. How have other plugins requiring compilation dealt with this? (Or are they simply not using cobertura?)

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxb2-maven-plugin</artifactId>
    <version>@project.version@</version>
    <executions>
        <execution>
            <id>schemagen</id>
            <goals>
                <goal>schemagen</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <!-- Whatever is needed for the IT -->
    </configuration>

        <!-- This dependency is required to execute mvn site in Mojo-Parent version 50 -->
    <dependencies>
        <dependency>
            <groupId>net.sourceforge.cobertura</groupId>
            <artifactId>cobertura</artifactId>
            <version>2.1.1</version>
        </dependency>
    </dependencies>
</plugin>

You received this message because you are subscribed to a topic in the Google Groups "mojohaus-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mojohaus-dev/uSZ83oGUEkQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mojohaus-dev...@googlegroups.com.

To post to this group, send email to mojoha...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAF8HOZKVc-6abVUen4EB_1XceqoP_FPS4M-jEi--mtTGqUaHrw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Jochen Wiedmann]

On Tue, Jul 9, 2019 at 7:44 PM Lennart Jörelid
<lennart...@gmail.com> wrote:
>
> Actually, it does not.
>
> The problem is that the IT:s in mojo-parent version 50 are run with Cobertura instrumentation.
> The implication of this is that the POM of each IT needs the Cobertura depdendency within the plugin dependencies when running the mvn site goal.

Would declaring the dependency as an extension help? See

https://maven.apache.org/guides/mini/guide-using-extensions.html

Jochen

[Lennart Jörelid]

Or we could simply remove the Cobertura plugin from the Mojo-Parent site, and include it for those plugins using Cobertura.

While I am uncertain about the state of the Cobertura running on Java8+ (and Java 11+ for that matter), it seems that the Mojo integrations with Cobertura requires quite a few complex twists within the POM - men to the point where it actually hampers progress. Could we remove it from the MojoHaus-Parent re-introduce Cobertura when it is actually updated for JDK 8+ or JDK 11+?

[Mirko Friedenhagen]

Hello Lennart,

+1 for removing cobertura from the mojo-parent, maybe meanwhile use jacoco instead?

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.
To post to this group, send email to mojoha...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/591a9b84-cf87-4e0b-9ef1-a75dca9f4850%40googlegroups.com.

[Lennart Jörelid]

There are several comparisons for code coverage project, such as the link below.

My preferences regarding a coverage tool would be something like:

• Alive community
• Functioning on JDK 8 and 11
• Maven Plugin integration
• Easy-to-read coverage report

I found only the following comparison, but others (and hopefully not done by one of the coverage tool teams) likely exist.

Do you have others? 

1. http://openclover.org/doc/manual/4.2.0/general--comparison-of-code-coverage-tools.html
   

Den onsdag 10 juli 2019 kl. 08:32:18 UTC+2 skrev Mirko Friedenhagen:

Hello Lennart,

+1 for removing cobertura from the mojo-parent, maybe meanwhile use jacoco instead?

Am 10.07.2019 um 05:13 schrieb Lennart Jörelid <lennart...@gmail.com>:

Or we could simply remove the Cobertura plugin from the Mojo-Parent site, and include it for those plugins using Cobertura.

While I am uncertain about the state of the Cobertura running on Java8+ (and Java 11+ for that matter), it seems that the Mojo integrations with Cobertura requires quite a few complex twists within the POM - men to the point where it actually hampers progress. Could we remove it from the MojoHaus-Parent re-introduce Cobertura when it is actually updated for JDK 8+ or JDK 11+?

Den tisdag 9 juli 2019 kl. 22:24:51 UTC+2 skrev Jochen Wiedmann:

On Tue, Jul 9, 2019 at 7:44 PM Lennart Jörelid
<lennart...@gmail.com> wrote:
>
> Actually, it does not.
>
> The problem is that the IT:s in mojo-parent version 50 are run with Cobertura instrumentation.
> The implication of this is that the POM of each IT needs the Cobertura depdendency within the plugin dependencies when running the mvn site goal.

Would declaring the dependency as an extension help? See

    https://maven.apache.org/guides/mini/guide-using-extensions.html

Jochen

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mojoha...@googlegroups.com.

[Mirko Friedenhagen]

Am 12.07.2019 um 08:47 schrieb Lennart Jörelid <lennart...@gmail.com>:

There are several comparisons for code coverage project, such as the link below.

My preferences regarding a coverage tool would be something like:

• Alive community

Define alive community: there is a user list where questions are answered, there are two very passionate developers who form the core. There is a user-list https://groups.google.com/forum/#!forum/jacoco

jacoco is the default coverage tool supported by Sonarqube for Java, the default in IntelliJ as well and has excellent Eclipse support as well (this is heresay, but Eclemma is based on jacoco).

• Functioning on JDK 8 and 11

As of version 0.8.4 (May 2019) jacoco even supports JDK12 https://www.jacoco.org/jacoco/trunk/doc/changes.html 

• Maven Plugin integration

Support is excellent IMO, you may even differentiate between unit (surefire) and integration (failsafe) tests. There is a merge goal to merge results from several modules. And there is a check goal to fail the build when coverage is too low. 

https://www.jacoco.org/jacoco/trunk/doc/maven.html

• Easy-to-read coverage report

https://www.jacoco.org/jacoco/trunk/coverage/ this is the report for jacoco itself.

One class: https://www.jacoco.org/jacoco/trunk/coverage/org.jacoco.core/org.jacoco.core.internal.analysis.filter/TryWithResourcesJavacFilter.java.html#L231

I found only the following comparison, but others (and hopefully not done by one of the coverage tool teams) likely exist.

Do you have others? 

1. http://openclover.org/doc/manual/4.2.0/general--comparison-of-code-coverage-tools.htm

I have used Atlassian Clover and Cobertura before and now use jacoco already for a couple of years. 

Clover had nice reports but instrumented source files and needed another compile, all in all it was dog slow, with WARs you did not test the final binary, handling was a mess. Reporting was nice though.

Cobertura was OK but development seemed to have stalled a bit.

jacoco works as an java-agent so it supports any JVM language (syntax highlighting in the report might be off a bit, though) and has a TCP server mode, i.e. you may even start your tomcat with it and dump the results after your tests. Overhead when running with jacoco is ~ 10%.

Of course you may call me opinionated jacoco still states that I am member of the core team. Unfortunately, as with mojohaus, I have very, very little time due to private obligations.

Best Regards

Mirko

Den onsdag 10 juli 2019 kl. 08:32:18 UTC+2 skrev Mirko Friedenhagen:

Hello Lennart,

+1 for removing cobertura from the mojo-parent, maybe meanwhile use jacoco instead?

Am 10.07.2019 um 05:13 schrieb Lennart Jörelid <lennart...@gmail.com>:

Or we could simply remove the Cobertura plugin from the Mojo-Parent site, and include it for those plugins using Cobertura.

While I am uncertain about the state of the Cobertura running on Java8+ (and Java 11+ for that matter), it seems that the Mojo integrations with Cobertura requires quite a few complex twists within the POM - men to the point where it actually hampers progress. Could we remove it from the MojoHaus-Parent re-introduce Cobertura when it is actually updated for JDK 8+ or JDK 11+?

Den tisdag 9 juli 2019 kl. 22:24:51 UTC+2 skrev Jochen Wiedmann:

On Tue, Jul 9, 2019 at 7:44 PM Lennart Jörelid
<lennart...@gmail.com> wrote:
>
> Actually, it does not.
>
> The problem is that the IT:s in mojo-parent version 50 are run with Cobertura instrumentation.
> The implication of this is that the POM of each IT needs the Cobertura depdendency within the plugin dependencies when running the mvn site goal.

Would declaring the dependency as an extension help? See

    https://maven.apache.org/guides/mini/guide-using-extensions.html

Jochen

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojoha...@googlegroups.com.
To post to this group, send email to mojoha...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/591a9b84-cf87-4e0b-9ef1-a75dca9f4850%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.

To post to this group, send email to mojoha...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/6cb82c8e-9828-45d3-aac8-4cf4c8339ae9%40googlegroups.com.