Repository navigation
[FEATURE] Ensure Java / Kotlin code is marked as generated #2295
Description
Why do we need this improvement?
This improvement is needed so that generated code can easily be excluded from quality analysis by standard JVM tooling.
How will this change help?
Some quality tools allow exclusion by filesystem path or package; others require annotations to exclude the code. This change will improve ease of use for JVM-based consumers.
Screenshots
No response
How could it be implemented/designed?
Any generated class must be annotated with jakarta.annotation.Generated to simplify excluding the code from various quality tools.
🚧 Breaking changes
No
👀 Have you checked for similar open issues?
- I checked and didn't find a similar issue
🏢 Have you read the Contributing Guidelines?
- I have read the Contributing Guidelines
Are you willing to work on this issue?
No, someone else can work on it.
Activity
GishReloaded commentedon Sep 17, 2026
Hi! I'd like to work on this if it is available.
I traced
asyncapi generate modelsand it delegates Java/Kotlin rendering to@asyncapi/modelina-cli, so the main implementation appears to belong inasyncapi/modelina, with the CLI consuming the updated Modelina version/options.My proposed approach:
jakarta.annotation.Generatedimport and annotation without affecting other languages.Could a maintainer confirm whether the implementation should be opened in
asyncapi/modelinaand whether all generated model types (classes, enums, records/unions) are expected to be annotated?michael-schechter-simspace commentedon Sep 22, 2026
@GishReloaded - That sounds like a good plan, and will address what I was looking for.
One suggestion - there are a couple of different
@Generatedannotations available; would it make sense to add a flag (like--javaJackson) to allow control of the annotation?Options include:
jakarta.annotation.Generatedjavax.annotation.processing.Generatedorg.springframework.aot.generate.GeneratedThanks for picking this up!
GishReloaded commentedon Sep 23, 2026
Thanks, that's helpful. A configurable annotation seems safer than choosing one for every Java/Kotlin consumer, especially since these variants have different dependencies. I'd keep existing output unchanged by default and check how Modelina options can be passed through the CLI before proposing the exact flag. For your tooling, would
jakarta.annotation.Generatedandjavax.annotation.processing.Generatedcover the need, or is the Spring AOT variant required too? I'd also appreciate maintainer guidance on the preferred implementation repository and scope before opening a PR.