> De: "Cédric Champeau" <cedric.champ...@gmail.com> > À: "dev" <dev@groovy.apache.org> > Envoyé: Vendredi 8 Septembre 2017 15:03:05 > Objet: Re: Groovy and code coverage
> Damn, who thought it was a good idea to put TIMESTAMPS in generated sources? It's a drop in replacement for javax.annotation.Generated [1] which is in a module what will be removed [2] from the modules of Java SE, so a long time ago :) Rémi [1] https://docs.oracle.com/javase/8/docs/api/javax/annotation/Generated.html [2] https://bugs.openjdk.java.net/browse/JDK-8152842 > 2017-09-08 15:00 GMT+02:00 Remi Forax < [ mailto:fo...@univ-mlv.fr | > fo...@univ-mlv.fr ] > : >> A standard annotation for generated code was added in Java 9: >> [ >> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html >> | >> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html >> ] >> Rémi >>> De: "Andres Almiray" < [ mailto:aalmi...@gmail.com | aalmi...@gmail.com ] > >>> À: [ mailto:dev@groovy.apache.org | dev@groovy.apache.org ] >>> Envoyé: Vendredi 8 Septembre 2017 11:41:18 >>> Objet: Groovy and code coverage >>> Hello everyone, >>> As you may be aware there are only a few choices in the Java pace that can >>> be >>> used for code coverage, JaCoCo being the one that gives the most accurate >>> results. While it's easy to setup JaCoco for Groovy sources there are times >>> where the tool reports no coverage for some lines of code that should not >>> have >>> been counted for coverage in the first case, these are some of the methods >>> coming from GroovyObject and AST transformations, specifically >>> `getProperty`, >>> `setProperty`, `getMetaClass`, and `invokeMethod`. >>> I had a chat with Marc Hoffmann yesterday about this situation, which is a >>> topic >>> we've discussed a few times in the past. I've got some good news, Groovy is >>> not >>> alone in this problem, the Lombok project has suffered the same fate which >>> has >>> prompted them to seek a solution. The alternative they came up with is to >>> have >>> Lombok identified generated code that should not be covered with a special >>> annotation (@lombok.Generated), JaCoCo has a filtering feature (not yet >>> public) >>> that can identify elements annotated with said annotation and skip them from >>> coverage reports. See >>> [ https://projectlombok.org/api/index.html?lombok/Generated.html | >>> https://projectlombok.org/api/index.html?lombok/Generated.html ] >>> [ https://github.com/jacoco/jacoco/pull/513 | >>> https://github.com/jacoco/jacoco/pull/513 ] >>> [ >>> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java >>> | >>> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java >>> ] >>> This feature will be available for consumption in the next releases of >>> Lombok >>> (1.16.8+) and JaCoCo (0.7.9+). >>> Given this, Marc suggested that Groovy could follow the same idea and >>> provide an >>> annotation that JaCoCo can identify, say for example >>> @groovy.transform.Generated. >>> If such annotation were to be added to Groovy we would need (at least) the >>> following steps too: >>> - update compiler to annotate `getProperty`, `setProperty`, `getMetaClass`, >>> and >>> `invokeMethod` when the class does not explicitly defines any of those >>> methods. >>> - review and update all core AST xforms that generate methods that should be >>> skipped from coverage. >>> - document the usage of this annotation and encourage AST xform developers >>> to >>> use it once they upgrade. >>> Would be great to have this feature in the 2.6.0 release if possible. >>> Thoughts? >>> ------------------------------------------- >>> Java Champion; Groovy Enthusiast >>> [ http://andresalmiray.com/ | http://andresalmiray.com ] >>> [ http://www.linkedin.com/in/aalmiray | http://www.linkedin.com/in/aalmiray >>> ] >>> -- >>> What goes up, must come down. Ask any system administrator. >>> There are 10 types of people in the world: Those who understand binary, and >>> those who don't. >>> To understand recursion, we must first understand recursion.
