Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have a @Generated with Retention Class, in addition of Source on generated builder #28

Open
alexandrenavarro opened this issue Nov 10, 2024 · 3 comments

Comments

@alexandrenavarro
Copy link

alexandrenavarro commented Nov 10, 2024

Have a @Generated with Retention = Class, in addition of Source on generated builder

It would be great to have a @Generated annotation with @Retention(RetentionPolicy.CLASS) in the generated builder like lombok @Generated annotation in addition of javax.annotation.processing.Generated with @Retention(RetentionPolicy.SOURCE) because jacoco uses it in order not to check test coverage on the generated classes.
I consider the builder should not be checked by jacoco as it is generated and because it should be tested by the generator itself in my opinion and today, in my project I tried to reach 100% of test coverage.

A potential solution is to let the user to configure extra annotation on the @Builder annotation on the builder generated class, like "extraAnnotationsOnBuilderClass" = "@lombok.Generated".
Another solution is just to have a @Generated with @Retention(RetentionPolicy.CLASS) in jilt and add add in the generator but this solution needs to have jilt not in maven scope provided but compile (personally, I like this solution less compared as the first one).
Maybe there are some other solutions.

It is clearly a nice to have feature, not a blocking feature.

Thank you for your useful lib and don't hesitate if you have questions.

@skinny85
Copy link
Owner

Thank for opening the issue @alexandrenavarro.

I think JaCoCo has multiple ways of excluding classes from coverage, right? Based on an annotation is just one of them. So you could do something like:

<plugin> 
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <configuration>
        <excludes>
            <exclude>yourpackage/**/*Builder.class</exclude>
        </excludes>
     </configuration>
</plugin>

And it should also work, right?

@alexandrenavarro
Copy link
Author

Yes it works.
But the problem is, I have some legacy hand-written classes in the real project named with *Builder which are kind of enhanced builder with some other functional methods and more checks that I can't change as basic builder.
In this case, I have 2 solutions :

  • if I used what you proposed, I removed the check of test coverage on all the Builder (hand-written and generated) what I don't want to do on hand-written classes.
  • I have to list all the generated builder in the build configuration file to exclude them one by one and I have to do it each time I used an new @builder which is painful.
    In my firm, we have some generators of classes and we annotated all with @jakarta.Generated (@retention(RetentionPolicy.SOURCE))+ @lombok.Generated (@retention(RetentionPolicy.CLASS)) on all the generated classes to solve the issue.
    Generally, the linter / checker are based mainly on the source files (like errorprone and many checkers) or sometimes on the class files (like jacoco, but it is less common).

@skinny85
Copy link
Owner

Can't you simply handle that case with the includes property?

So, something like this:

<plugin> 
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <configuration>
        <excludes>
            <exclude>yourpackage/**/*Builder.class</exclude>
        </excludes>
       <includes>
            <include>yourpackage/ManualBuilder.class</include>
            <!-- repeat as needed for all manually-written builders... -->
       </includes>
     </configuration>
</plugin>

This way, the manually written classes will still be checked, but new classes using Jilt will be automatically excluded?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants