Moshi: Allow custom @Generated annotations

[marcinbak]

I'm using Moshi code generation in a project with strict code coverage requirements and JaCoCo for code coverage reporting.
JaCoCo can ignore classes and methods annotated with annotation whose retention policy is runtime or class and whose simple name is Generated.
Would it be possible to give developers possibility to use custom defined Generated annotation as moshi.generated? Now we are limited to javax.annotation.Generated which has source retention policy only, thus is not ignored by JaCoCo and generated adapters decrease coverage.

[swankjesse]

You should relax your counterproductive policy and fix your tools to omit generated source directories in its report.

[realdadfish]

The new version of Jacoco (0.8.3) relaxes the strictness a bit and allows for any custom annotation with BINARY or RUNTIME retention as long as it's simple name just contains the name "Generated". I'd still love to see the annotations added to the adapters. Configuring exclude paths in a multi-module project that uses Moshi's codegen in various places is cumbersome.

[ZacSweers]

I added/pushed for the existing support for basically that use case, but I think that limiting it to the javax generated annotations is good enough. This lines up with other common code generation tools as well, such as Dagger, AutoValue, etc.

Since it's generated code that you're not looking at anyway, why not just use the javax annotation for Moshi as a compileOnly dependency and continue using your preferred one everywhere else?

[realdadfish]

Well, I have absolutely no preferences what kind of annotation Moshi uses, it should just be recognized by Jacoco :)

[ZacSweers]

It sounds like you're good to go then if it recognizes any annotation with Generated in the name then. Mind if we close this out?

[marcinbak]

I'm not sure I understand the suggested solution.
Moshi generates classed that can be annotated with javax annotation which has SOURCE retention.
JaCoCo ignores classes and methods based on annotation containing string Generated but they must be BINARY or RUNTIME retention.

How does

Since it's generated code that you're not looking at anyway, why not just use the javax annotation for Moshi as a compileOnly dependency and continue using your preferred one everywhere else?

solve this?

[ZacSweers]

I didn't realize the javax one was source retention! That said, still seems like a silly limitation of jacoco

[marcinbak]

JaCoCo works on bytecode, not on source code as far as I remember thus the limitation.

[ZacSweers]

Then I'd recommend what Jesse said initially. Kapt outputs to deterministic locations, always relative to the current build directory. Moshi uses generated directory that kapt specifies, so it should line up to that.

[marcinbak]

Thanks for help.
That gives me an idea to build exclusion list based on generated files, but as those are Java, Kotlin source files it wouldn't be complete solution (doesn't count inner classes, or multiple classes defined in one Kotlin file).
Will need to investigate this further, it would be nice to have a standard when it comes to code coverage and generated code. For now I know Lombok is using Generated annotation that has BINARY retention.

[realdadfish]

I figured it seems to be possible to configure a custom annotation class now that solves the issue, nice!

kapt {
    arguments {
        arg("moshi.generated", "path.to.annotation.with.binary.retention.Generated")
    }
}

(Source: https://www.zacsweers.dev/exploring-moshis-kotlin-code-gen/)