Adding @Generated annotation for generated code for code coverage purposes

[yonatang]

Hi,

Right now, if you would naively use DGS generated code, the code would be scanned by code coverage tools, and most likely to be reported as missing coverage, as it makes little sense to fully test generated code (as reported at Netflix/dgs-codegen#420).

Code generation frameworks usually allow to add a @Generated annotation on such classes (i.e. Lombok's addLombokGeneratedAnnotation, or addGeneratedAnnotation in graphql-java-codegen). I believe most code coverage tools could be configure to skip @Generated annotated classes.

I wish to add a feature that will allow to add @Generated annotation on the generated sources. It could be a flag with a false default value, which would guarantee backwards compatibility. I believe the approach implemented in graphql-java-codegen here would work well in this project as well - it would detect that which (and if) @generated annotation is available on the classpath, to eliminate potential javax.annotation.processing.Generated vs javax.annotation.Generated issues.

Please let me know what do you think.

[srinivasankavitha]

I think that makes sense to add. Any PR contributions appreciated!

…

On Tue, Jul 12, 2022 at 11:33 AM Yonatan Graber ***@***.***> wrote: Hi, Right now, if you would naively use DGS generated code, the code would be scanned by code coverage tools, and most likely to be reported as missing coverage, as it makes little sense to fully test generated code (as reported at Netflix/dgs-codegen#420 <Netflix/dgs-codegen#420>). Code generation frameworks usually allow to add a @generated annotation on such classes (i.e. Lombok's <https://projectlombok.org/features/configuration> addLombokGeneratedAnnotation, or addGeneratedAnnotation in graphql-java-codegen <https://github.com/kobylynskyi/graphql-java-codegen/blob/master/docs/codegen-options.md>. I believe most code coverage tools could be configure to skip @generated annotated classes. I wish to add a feature that will allow to add @generated annotation on the generated sources. It could be a flag with a false default value, which would guarantee backwards compatibility. I believe the approach implemented in graphql-java-codegen here <https://github.com/kobylynskyi/graphql-java-codegen/blob/master/src/main/java/com/kobylynskyi/graphql/codegen/model/GeneratedInformation.java> would work well in this project as well - it would detect that which (and if) @generated <https://github.com/generated> annotation is available on the classpath, to eliminate potential javax.annotation.processing.Generated vs javax.annotation.Generated issues. Please let me know what do you think. — Reply to this email directly, view it on GitHub <#1147>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXNX5ASECO6WXMDSRRTVTW26RANCNFSM53L65NJA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[yonatang]

Netflix/dgs-codegen#424

[srinivasankavitha]

Released in v5.2.5

[yonatang]

Hello @srinivasankavitha,

@bartebor just made me aware Jacoco won't pick up the @javax.annotation{.processing}.Generated annotation, as it has a SOURCE retention policy: jacoco/jacoco#831 (comment)

Seems that Jacoco will pick any annotation with the simple name Generated, regardless of the package, as long as it has CLASS or RUNTIME retention. I feel the best solution is to keep the javax Generated annotation with the metadata (SOURCE retention, no harm in keeping it), and add another custom annotation, in the user provided package named @Generated with a CLASS retention, which will provide the ability to exclude these classes from code coverage.
For example, let's say the user generating code with the package com.acme.anvils. If the addGeneratedAnnotation is on, CodeGen will generate a com.acme.anvils.Generated annotation with BINARY/CLASS retention (for Kotlin/Java respectively), and then the generated code will look like:

@javax.annotation.Generated(value="com.netflix.graphql.dgs.codegen.CodeGen",date="2022-08-08T21:37")
@com.acme.anvils.Generated()
public class AnvilStand { 
...
}

While one might consider that as a Jacoco-specific feature, I'll argue that only two active OSS code coverage projects exists: Jacoco and Intelliji-Coverage; Jacoco is by far more popular, and either way, Intelliji-coverage doesn't have any similar capabilities right now (see IDEA-292401 and IDEA-266202). So it would make sense to have it supported by Jacoco only.

If that makes sense, I'll provide a PR to remedy this.