It sounds like we should keep the Generated annotation on Trait-private methods then, and use it going forward on any new framework Traits.
Thank you! /Mattias Den ons 29 okt. 2025 kl 06:08 skrev Paul King <[email protected]>: > > I am not sure if it is needed in that particular case. I know there > was a time when requests were made in similar cases to please coverage > tools. Sometimes the generated methods can be more difficult to get > full test coverage for, so some tools just ignore any generated > methods when calculating coverage percentages. A purest could argue > that you'd want full coverage of those methods also, but at the time > we were shown enough cases that convinced us it was worth adding. I > don't know if Grails would be impacted by the same problem, but it > gives some background as to why it may have been done. > > Cheers, Paul. > > On Wed, Oct 29, 2025 at 12:27 AM Mattias Reichel <[email protected]> wrote: > > > > We have recently merged a PR[1] in Grails that adds the > > groovy.transform.Generated annotation to all Trait methods so that > > they do not screw up test coverage statistics when they are added to > > implementing classes. > > > > I noticed that the PR also added the annotation to private methods in > > the Traits and I am curious if this is necessary? > > > > According to AI: > > > A private method in a Groovy Trait is trait-private: it’s compiled into > > > the trait’s helper class and used only by other methods in the trait. It > > > is not added to (or visible on) the implementing class, so you can’t call > > > it from the class (or from other traits). > > > > > A trait-private method is already an internal implementation detail and > > > won’t be added to or visible on implementing classes. Annotating it with > > > @Generated doesn’t change semantics or visibility. > > > > Thanks for any wisdom on this! > > /Mattias > > > > [1] https://github.com/apache/grails-core/pull/15150
