Use APT to generate code on compilation

[gzsombor]

Overview of the feature request

As JHipster generates lots of boilerplate source code, which could be intimidating or annoying - especially for entities with long list of fields (for DTOs, Criteria objects, etc...), and with MapStruct or the Hibernate Static Metamodel generator it is a proven path to reduce the repetitiveness, I'm suggesting to use APT to generate part of our code on compilation instead of project setup/re-generation.

Motivation for or Use Case

DTOs and Criteria objects are really long and boring code, and most of the cases it's just waste - for example adding 5 fields to an entity, currently result in a lot of changes in the generated code, and reviewing these changes are annoying - easy to miss the important changes. The other problem which I regularly face, is that after a generated project matures a bit, using the current JHipster generators to add new fields, or regenerate the project is much bigger task that used to be. (Because the customization is everywhere, for example having a @Version field, which needs special handling, or custom field types...)
My idea is to develop annotations and annotation processing tools to improve the situation.
Imagine, for a starter, instead of generating all the DTOs and criteria objects, on your entity you could write:

@Entity
@GenerateBean(package="com.mypackage.dto", suffix="DetailedDTO", 
   excludeFields = [ "version", "otherEntities" ], 
   addNewField = [ @ExtraField("String", "someValue") ], 
   constructorStyle = NO_ARG_AND_FULL, 
   typeConversion = [ @TypeConversion("UUID", "String") ])
class MyEntity {

And you would get a com.mypackage.dto.MyEntityDetailedDTO with all the fields from MyEntity, minus the version and 'otherEntities', but a String someValue is added, and all the UUID fields are mapped to String.

If someone needs to customize the generated code, they could easily do it, with copying the generated source to in their source folder, and remove the annotation. Or if it's enough, they can just extend the generated java class in their project.
With this annotation based approach we wouldn't need to maintain the separate UserDTO templates anymore, I believe.

Related issues or PR

I'm sure, there were tickets about the huge amounts of code generated ...

• Checking this box is mandatory (this is just to show you read everything)

[pascalgrimaud]

@gzsombor : it's an important subject, so you should post a mail to the mailing list and mention this ticket. It needs to be discussed before doing something

[ko5tik]

Do I hear xdoclet revival? We may still have templates for it somewhere. Actually not having those code under version control is a great idea

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[gzsombor]

Lets reopen, I've started working on this ...

[vishal423]

Have we considered use of Java record ?

[gzsombor]

Yes, definitely. I'm not sure what kind of customization could be feasible, I would really like to have the possibility to even extend the logic by anyone. But I'm a bit concerned the classloading issues on source generation.
But as JHipster currently doesn't target Java 16, we can't generate Java records by default. And as I saw, JavaPoet does not support Java record generation - even though a pull request is out there to add: square/javapoet#829 - and there were no recent activity on that project, I fear, we have to wait a little bit.

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[DanielFran]

@gzsombor, what is the current status? Are you still available to create a PR?

[github-actions]

This issue is stale because it has been open for too long without any activity.
Due to the moving nature of jhipster generated application, bugs can become invalid.
If this issue still applies please comment otherwise it will be closed in 7 days