Damn, who thought it was a good idea to put TIMESTAMPS in generated sources?
2017-09-08 15:00 GMT+02:00 Remi Forax <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 > > Rémi > > ------------------------------ > > *De: *"Andres Almiray" <aalmi...@gmail.com> > *À: *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://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 > > 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://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. > >
