You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Use annotation for generated code instead of comment #144
It would be useful to have a javax.annotation.Generated annotation for each generated class instead of the current code comment header. This would prevent generated code from multiple scanning jobs out of the box (like spotbugs and jacoco) instead of additional tool configurations to prevent this.
Filling the date() of the annotation should be configurable (options.suppress-generator-timestamp: true) so generated classes would not differ without API changes.
I can add something like this but I would like to understand where the benefit is. :-)
I looked at it in the past and decided against it because I didn't really see the benefit in it (I probably didn't investigate very much) and because it is an annotation processing specific annotation. It doesn't seem to be a general annotation for generated code.
With a quick search I found the following issues and it looks like spotbugs/jacoco do/can not use that information:
You are right, Lombok has its own annotation with runtime retention. So openapi-processor could follow this approach and offer its own annotation to make such tool integration easier (I don't think it should allow any external annotation to be used). By doing so, replacing the comment is less useful and could be skipped.
(Btw, I had the wrong annotation package in the original comment, sorry)
yes, guess we need our own @Generated annotation with retention runtime (class may work too).
should it generate {package-name}.Generated or a use a common package name io.openapiprocessor.annotation.Generated.
I think I prefer the first variation.
Parameters would be similar to javax @Generated: value (generator) and date and a fixed comment. This could replace the header comment (ah, that would require an update all the integration tests... ;-).
Activity
hauner commentedon Aug 12, 2022
I can add something like this but I would like to understand where the benefit is. :-)
I looked at it in the past and decided against it because I didn't really see the benefit in it (I probably didn't investigate very much) and because it is an annotation processing specific annotation. It doesn't seem to be a general annotation for generated code.
With a quick search I found the following issues and it looks like spotbugs/jacoco do/can not use that information:
spotbugs/spotbugs#464
jacoco/jacoco#831
Looking at this
https://stackoverflow.com/questions/47824761/how-would-i-add-an-annotation-to-exclude-a-method-from-a-jacoco-code-coverage-re
jacoco ignores code annotated with any
Generatedannotation that has runtime retention.To support this we would need a configurable annotation. That should be easy. Configuring parameters for it would be more interesting... ;-)
aburmeis commentedon Aug 15, 2022
You are right, Lombok has its own annotation with runtime retention. So openapi-processor could follow this approach and offer its own annotation to make such tool integration easier (I don't think it should allow any external annotation to be used). By doing so, replacing the comment is less useful and could be skipped.
(Btw, I had the wrong annotation package in the original comment, sorry)
hauner commentedon Aug 16, 2022
yes, guess we need our own
@Generatedannotation with retention runtime (class may work too).should it generate
{package-name}.Generatedor a use a common package nameio.openapiprocessor.annotation.Generated.I think I prefer the first variation.
Parameters would be similar to
javax @Generated:value(generator) anddateand a fixedcomment. This could replace the header comment (ah, that would require an update all the integration tests... ;-).openapi-processor/openapi-processor-spring#144, integration test
openapi-processor/openapi-processor-spring#144, generated annotation
openapi-processor/openapi-processor-spring#144, pending test
openapi-processor/openapi-processor-spring#144, improve/fix integrati…
openapi-processor/openapi-processor-spring#144, improve generated writer
openapi-processor/openapi-processor-spring#144, generate Generated
openapi-processor/openapi-processor-spring#144, extract interface
openapi-processor/openapi-processor-spring#144, simpler generated gen…
openapi-processor/openapi-processor-spring#144, write @generated on d…
2 remaining items
openapi-processor/openapi-processor-spring#144, write @generated on m…
openapi-processor/openapi-processor-spring#144, write @generated on i…
openapi-processor/openapi-processor-spring#144, fix
openapi-processor/openapi-processor-spring#144, update generated files
openapi-processor/openapi-processor-spring#144, generated date switch
openapi-processor/openapi-processor-spring#144, generated date option
openapi-processor/openapi-processor-spring#144, fix package
openapi-processor/openapi-processor-spring#144, fix default values
openapi-processor/openapi-processor-spring#144, fix tests
#144, update to @generated
#144, simpler
openapi-processor/openapi-processor-spring#144, generated date option
#144, add documentation
hauner commentedon Oct 13, 2022
released with 2022.5