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

[Task] Extend code generation with option for POJO setters #695

Open
andreas-schilling opened this issue Jan 10, 2025 · 0 comments
Open
Labels
acknowledged Has been viewed by one of the maintainers and is ready for further work, discussion or other steps. task

Comments

@andreas-schilling
Copy link
Contributor

Is your task related to a problem? Please describe.
Currently POJOs are generated with immutability built in. A full constructor is generated and then for each property one getter.
As long as the POJOs are used to only consume upstream data or are always fully initialized prior to passing them on (e.g. to the API of an aspect implementation for serialization to JSON) this is fine.
However in situations where data can only be partially initialized and is added later in the process (e.g. through some sort of post-processing) this can be unhandy, as it requires a developer to always fully initialize a new instance, taking the properties from an existing one when they should be used unmodified and then passing the updated/new property values for everything else.

Describe the solution you'd like
The POJO generator (or rather the templates) should be extended, so that with an additional option it can be decided, whether also setters should be generated. By default the current variant should be used where only getters exist.

Additionally one could also think about providing an additional parameter that drives how the setters are generated: either in a classic setter style (void method) or in a fluent builder style (where this is returned for method chaining)

Additional context
See #534

@atextor atextor added the acknowledged Has been viewed by one of the maintainers and is ready for further work, discussion or other steps. label Jan 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledged Has been viewed by one of the maintainers and is ready for further work, discussion or other steps. task
Projects
None yet
Development

No branches or pull requests

2 participants