Generator-jhipster: [enhancement] Introduce immutable.io processor for generating builder

[Tcharl]

Overview of the issue

Fluent setter are part of the generated code, which lead to some boilerplate stuff to maintain without any real value.
I made a PoC of immutable.io to automatically generate builder for element (keeping the mutating stuff for the moment, as mapstruct 1.2 do not handle it very well for the moment (it's on the 1.3.0 roadmap).

Motivation for or Use Case

Remove the 'nofluent' option from jdl, keeping code clean and readable

Reproduce the error

Generate some entities with attributes ^^

Related issues

5830, but the solution is quite different (removed boilerplate, which causes this one to be removed)

and mapstruct builder follow up for the future for future DTO immutability (\o/ one more antipattern which will be removed).

Suggest a Fix

Adding an empty constructor plus an all arg constructor on every entities and DTO. the later will be annotated with @org.immutables.builder.Builder.Constructor, also adding immutable.io value and builder dependencies (and reference value as processor) within the project pom.
Then, we'll be able to use the automagically generated new <entity>Builder().<attribute>(val)...build() in every tests, services and so on.

JHipster Version(s)

4.11.1

JHipster configuration

Not concerned

Entity configuration(s) entityName.json files generated in the .jhipster directory

Any jdl entity with attribute without the 'nofluent' option

Browsers and Operating System

Any

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

However, I can handle the according PR.
WDYT?

[deepu105]

I haven't tried Immutable.io but it sounds similar to Lombok and If so I don't think we want that.

[Tcharl]

It's a real java processor, like mapstruct, not a magical thing or an IDE plugin.
It's debuggable (not like lombok): generated classes are on the 'generated-sources' package, and really simple.

[deepu105]

Anyway I have added the discussion label. Lets wait for the @jhipster/developers opinion

[jdubois]

We already have a lot of trouble with annotation processors, as they don't work out-of-the-box with IDEs. I don't understand why, but that's the way it is.

[Tcharl]

I don't have any with either IJ or Eclipse, but I maybe lucky :-).

Concerning Eclipse, there's may be a lifecycle plugin tweak to make, concerning IJ there must be another way: let me investigate on this ASAP in order to improve the 'Developer experience' ;-)

[jdubois]

Have a look at our "ide" Maven profile

[Tcharl]

I already looked at it, but it looks useless to me after some pom engineering (don't know for Gradle, I've never used it).

[jdubois]

Anyway, we can't do any big refactoring or big study at the moment: we have more than 40 opened tickets, those are the priority, not the new features. I hope it will get better soon.

[pascalgrimaud]

As Julien said, we have too many opened tickets.
We should not do new features right now

[atomfrede]

Immutables.io is a great project and totally different from lombok. But I don't think we can handle another option here currently. And the benefit for the user is not that high. In the long term it could help us as we need to code less things ourselves.

[sendilkumarn]

Lets close this, since we have way too many tickets opened.