JDl code generation and Open Close principle

jnsunkersett commented 5 years ago

Overview of the feature request

Hello, From the JDL, JHipster generates the Entity, ServiceImpl and related interfaces
I need to write custom code, on top of the generated code - where should I keep it?

One place is to edit the generated code and insert custom code inside them. But this defeats the Open Close principle. Also the next time the JDL is modified imported - and each time the generated classes are overwritten and my custom code will be lost. ( The JDL modification can be - a new entity is added, a column is deleted or data type is changed in an existing entity, etc.) Another alternative can be extend generated code and write custom code in the extensions - so that it is not overwritten when modified JDL is re-imported (maximum compilation errors are introduced in custom code and they would need to be fixed manually. This way the Open Close principle is adhered too as well. But this way my code base becomes heavy - as lot many java classes will have to be maintained (youtube url below).

So we need a middle route. Any suggestions/ comments?

thank you Jeevan

Motivation for or Use Case

Adhere to S.O.L.I.D practices (and in specific the Open Close principle).

Related issues or PR

This feature has already been raised but could not locate any resolution.

Also described on YouTube : https://www.youtube.com/watch?v=9WVpwIUEty0
jhipster-core GitHub : https://github.com/jhipster/jhipster-core/issues/13
jhipster-core GitHub : https://github.com/jhipster/jhipster-core/issues/259

[x] Checking this box is mandatory (this is just to show you read everything)

Tcharl commented 5 years ago

Extending services, resource and frontend classes is not that hard, is it?

Every other alternatives that has been tried have failed due to poor developper experiences:

Acceleo with its //begin of user code //end of user code.
Diff/merge.

A last alternative would be to regenerate your code in another branch than your main one and cheery pick changes.

jnsunkersett commented 5 years ago

Thank you Charlie.

Extending services, resource and frontend classes is not that hard, is it? It is not, but may result in an increase in the number of classes. (and in Git) that need to be maintained.

I am not in favor generating code in one branch and custom code in another and cherry picking them during merge.

Diff/merge using Liquibase diff command seems cumbersome.

So thinking of employing an approach of multiple maven projects

Project 1, has only JDL and uses Liquibase to generate the related code.
Project 2 will hold the custom code and use project 1 as a dependency.
both of the above is bundled into another maven project (project 3)

thanks Jeevan

MathieuAA commented 4 years ago

@jnsunkersett I guess everyone forgot about this issue... the answer is simple: you keep it with your generated code and use the "side-by-side" pattern. You generate code with JHipster, but don't modify it. Instead, you extend/compose the generated classes with new ones (the custom code). That's what the video is about, and your suggestion as well. This is not an issue with the JDL, but with generators in general.

jhipster / jhipster-core