search

Netflix / dgs-codegen

Apache License 2.0
183 stars 99 forks source link

Use kotlinx.serialization instead of Jackson for generated types #353

Open JUSTINMKAUFMAN opened 2 years ago

JUSTINMKAUFMAN commented 2 years ago

It would be great if we could do something like:

generateJava {
    generatedTypesSerializer = "kotlinx.serialization" // Default: "jackson" (use `null` to omit serialization annotations altogether)
}

Assuming we cannot do this right now, is there a recommended way to customize the generator to make it do something like this in our own project?

itsandreramon commented 2 years ago

Wondered the same. What do you think? @berngp

JUSTINMKAUFMAN commented 2 years ago

Another thought:

I wound up writing a custom gradle routine to strip out any/all dependency-opinionated annotations/imports from the generated models so that the end result is a set of “vanilla” Kotlin types.

I then have another script that adds the kotlinx.serialization @.***` annotation to generated data classes.

I mention because, unless the authors consider serialization support as being necessarily coupled with the generated types, I would suggest enabling features like this as optional customizations.

Given the rising popularity of Kotlin Multiplatform (not to mention the fact that Netflix itself purportedly uses it), I imagine many folks who use this plugin will want nothing more than the plain ‘ol models themselves.

On Tue, Mar 29, 2022 at 10:03 AM André Ramon @.***> wrote:

Wondered the same. What do you think? @berngp https://github.com/berngp

— Reply to this email directly, view it on GitHub https://github.com/Netflix/dgs-codegen/issues/353#issuecomment-1082137590, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHCY545AYUDPI347FNWN43VCMZUXANCNFSM5QQPVQNQ . You are receiving this because you authored the thread.Message ID: @.***>

srinivasankavitha commented 2 years ago

That's a good idea @JUSTINMKAUFMAN. For internal usages, we do have it coupled and haven't had the need to explicitly disable it (also because we have minimal kotlin usage currently). That said, we also welcome any PRs for this effort. Due to the lack of internal need for this, we won't be prioritizing it anytime soon.