GROOVY-8352 #617
GROOVY-8352 #617
Conversation
| * | ||
| * @author Andres Almiray | ||
| * @author Jochen Theodorou | ||
| * @author Mark Hoffmann |
There was a problem hiding this comment.
Actually, we are mostly trying not to use @author tags these days - though we haven't made it mandatory.
Apache encourage removal of @author tags. It's not a mandated rule but they err on the side of wanting the whole community to own the whole codebase rather than potential contributors being put off by not wanting to touch a file "owned" by someone else. Git will tell us who the contributor was on a more fine-grained and accurate level than such tags anyway but obviously won't capture multiple authors committing under one of those names. Make sure anyone who has made a significant contribution is added into the pomconfigurer.gradle file.
There was a problem hiding this comment.
@paulk-asert I'm completely o.k. with removing my name here at all.
There was a problem hiding this comment.
@marchof the pomconfigurer.gradle file is a good option too Marc! :-)
|
I get the same failures locally as travis-ci. I haven't had time to fully investigate but it seems like we can get away without setting a source unit when we create little snippets by hand (in our test code for instance) so long as we don't have any annotations in those snippets. While I wonder whether checking for version >= jdk5 with |
|
The test for |
| if (!node.isDerivedFromGroovyObject()) node.addInterface(ClassHelper.make(GroovyObject.class)); | ||
| FieldNode metaClassField = getMetaClassField(node); | ||
| AnnotationNode generatedAnnotation = new AnnotationNode(ClassHelper.make(GENERATED_ANNOTATION)); | ||
|
|
There was a problem hiding this comment.
I needed a guard on adding the annotation to keep the build happy:
boolean shouldAnnotate = classNode.getModule().getContext() != null;
There was a problem hiding this comment.
2 small fixes added 😄
|
FYI: The filter for the new annotation will be part of JaCoCo 0.8.0 release soon. |
|
I pushed the branch. I do agree we should have a guideline for when to use it and when not. But I think we should first start using it and then decide what we want to advice |
|
I see it is not adding the @generated annotation to get/set methods generated by groovy for private variables. As a result code coverage reports are still not that accurate as code coverage reports still show get/set methods not covered. |
|
You mean for example in class X{def y} the getY and setY method? |
|
Yes.. |
|
Any thoughts on above request to add @generated annotation for Groovy generated get/set methods for private variables? |
|
Hi @aalmiray / @blackdrag , I wonder why the auto-generated setters and getters, as well as equals / hashcode are not also marked as I have the following class: I am getting this coverage report: I am using Groovy 2.5.1 and JaCoCo 0.8.1. This class was supposed to have 100% code coverage. Also something I get coverage saying I have not covered all branches of a line, but the line has just one branch:
What do you guys think? |
|
@michelzanini as of Groovy 2.5.2/3.0.0-alpha-3 getters/setters and many methods added by core AST transformations are not marked with |
6 participants
See https://issues.apache.org/jira/browse/GROOVY-8352
Retention policy is set to
RUNTIMEin order to allow frameworks and libraries to have access to the new metadata.There's a breaking change in
Verifier, a protected method now returnsMethodNodeinstead ofvoid. This change was reviewed with @blackdrag and deemed the better solution among alternatives (such as duplicate method & deprecate old).The JaCoCo team has done their part to prepare their project for this new annotation (see jacoco/jacoco#610).