Filter for Groovy generated methods #610
Conversation
|
Here's the Groovy side of the equation apache/groovy#617 |
|
@datoma @aalmiray cool! thank you for contribution! 👍 @aalmiray impatient to try full end-to-end example, so same questions as from @marchof plus maybe you can advise some Groovy-based project where JaCoCo is already used, so that we'll be able to use it as such end-to-end example? And in any case it can be a nice addition for page https://github.com/jacoco/jacoco/wiki/Projects-that-use-JaCoCo 😉 Also wondering if you know examples of generated code that might require filtering and is not represented by generated methods, but is inside of non-generated methods? |
|
@Godin Groovy side has been merged on |
| } | ||
|
|
||
| private boolean hasAnnotation(final MethodNode methodNode) { | ||
| final List<AnnotationNode> runtimeInvisibleAnnotations = methodNode.invisibleAnnotations; |
There was a problem hiding this comment.
In contrast to Lombok, Groovy adds visible annotation, while here we check only invisibleAnnotations, so that currently filter doesn't work.
There was a problem hiding this comment.
@marchof nothing extraordinary - I'm simply doing end-to-end testing 😉
| Initial analysis and contribution by Rüdiger zu Dohna. | ||
| (GitHub <a href="https://github.com/jacoco/jacoco/issues/513">#513</a>).</li> | ||
| <li>Exclude from a report methods which are annotated with <code>@groovy.transform.Generated</code> | ||
| to better integrate with Groovy >= 2.6.0. Thanks to Andres Almiray to make this possible! |
There was a problem hiding this comment.
I'm not a native English speaker, but "to make this possible" looks/sounds weird for me.
There was a problem hiding this comment.
Also I believe that >= 2.6.0 should be replaced by >= 2.5.0 since change on Groovy side was merged not just into master and 2_6_x branches, but also into 2_5_x.
There was a problem hiding this comment.
I guess "Thanks to Andres Almiray for making this possible!" would work, but perhaps just rephrase to match the preceding bullet or say "for the contribution" or something.
There was a problem hiding this comment.
@bjkail Thanks for your input! What I want to express here that Andres triggered the introduction of the annotation in the Groovy compiler.
There was a problem hiding this comment.
Ah, then "for making this possible" would work, but "this" seems ambiguous, so I would say "for adding the annotation to Groovy, which made this possible" (or "starting the discussion to add the annotation to Groovy", or whatever was done :-)).
| import org.objectweb.asm.tree.MethodNode; | ||
|
|
||
| /** | ||
| * Filters which filters annotated methods. |
There was a problem hiding this comment.
Also I'm wondering why abstracting instead of having simply one class that will handle both annotations?
There was a problem hiding this comment.
@Godin I would prefer to have a separate class for every filter:
- Separate testing of different concerns
- Possibly enable/disable filters separately
- I could imagine that we add meta methods/annotations to filters for generating documentation
|
End-to-end test - example.zip Without this change using JaCoCo 0.7.9: After this change: |
Godin
force-pushed
the
groovyGeneratedFilter
branch
from
a307ddc to
3921698
Compare
|
Have to check again with @blackdrag why the |
|
@aalmiray well, in any case they are filtered 😉 I was more wondering why generated setters and getters do not have nor line numbers (was expecting line of a field), nor annotation? But that's not so important for end-to-end test here and now that's entirely up to you, Groovy-guys, to mark whatewer you want 😉 Thanks again! 👍 Great collaboration! ❤️ |
5 participants
Hackergarten Bern Session, co-hacked with @aalmiray and @marchof