Generator-jhipster: Use lombok in generated project

[sidharta]

Use projectlombok.org to replace getters and setters in code.

[jdubois]

No, I'm against Lombok from the beginning (you are not the first one to ask!)

This looks like a good idea, but believe me, I've seen on several projects, and we kept having issues and bugs etc... with Lombok. I've already lost far too much time because of Lombok.

Besides, we also generate getters/setters/equals/hashcode...

[sidharta]

That's alright! I have a great experience with lombok and several success projects in production... Shouldn't we provide an option for that at the jhipster menu?

[jdubois]

We already have 13 options, and I don't want to add a new one without a very good reason.
I've seen Lombok cause trouble in my CI environnement, confuse developers, etc... This is just too much trouble compared to what we gain.

[codestrong]

I'd also like to see Lombok added to JHipster. Be that as a default or an option.

Julien, why not have a discussion about this? The "I don't like it" bit sounds more like a tantrum, sorry :)

[pascalgrimaud]

@codestrong : it has been already discussed a lot. You can read old tickets here https://github.com/jhipster/generator-jhipster/issues?utf8=%E2%9C%93&q=lombok

I completely agree with "This is just too much trouble compared to what we gain."

But, why not trying to do a module for that ? https://jhipster.github.io/modules/creating-a-module/

[deepu105]

I have seen people not liking the generated DTO part due to mapstruct so adding more stuff like that is not really something I would like as well

[codestrong]

I have read the other topics about this and it sounds like it comes down to personal feelings rather than reason

[codestrong]

Maybe another solution can be found? For example Spring Roo used to store getters/setters in an aspect. Having so much boilerplate code in domain classes is not ideal.

[tezcane]

For stuff like this, what if we add some section in the .yo-rc.json file so power users can use at their own risk, e.g.:

{
  "generator-jhipster": {
    "jhipsterVersion": "4.3.0",
     ...
    "unrecommended-options":  [    <- new section
         "lombok",                 <- extra option 1
        "user.mobileNum"           <- extra option 2
     ]
    ...
}

With this approach the menu is simple but power users (most devs) can tweek to their hearts delight.

Personally, I will go through 50 menu items if it means I don't have to fiddle with as much code. For example, it is so annoying to go change the SQL ports after generation that used to be there. It is much easier to answer a few extra questions in prompt which I will do one time per project then go edit code for hours.

As far as Modules go, I have not understood how exactly they will manipulate the project... they should be categorized somehow to show different areas that they will add code to. I was not able to find ample documentation on this. My 2 cents. One day I am going to make a lot of edits to the docs...

And throwing tantrums is the right of all developers.

[tezcane]

Maybe in the new menu options that lists ALL the modules... it can be made into categories like mentioend above (user would not have to edit .yo-rc.json then too).

[ruddell]

@tezcane That's exactly what modules do. It's also hard to categorize modules because they can be simple or advanced, and can change any part of the project.

For example, https://github.com/hipster-labs/generator-jhipster-entity-audit/ changes some files on the initial run (like adding a frontend page), then updates entity files. It also adds a hook that runs on entity generation, so new entities receive the same benefits without having to re-run the module. This adds to the .yo-rc.json:

 "generator-jhipster-entity-audit": {
    "auditFramework": "custom"
  }

And the entity generation hook (.jhipster/modules/jhi-hooks.json):

[
    {
        "name": "Entity Audit generator",
        "npmPackageName": "generator-jhipster-entity-audit",
        "description": "Add support for entity audit and audit log page",
        "hookFor": "entity",
        "hookType": "post",
        "generatorCallback": "jhipster-entity-audit:entity"
    }
]

That hook adds a question to the end of the entity generation process:

Reading the JHipster project configuration for your module
? Do you want to enable audit for this entity(Foo)? (Y/n) 

This is then saved in the entity's JSON file as a new key:

    "enableEntityAudit": true

Most modules update/replace content in files by string-replace or regex by using this method from JHipster. The other available JHipster methods can be seen here

This could easily be done for Lombok, the problem is that someone has to take the time to write the module and maintain it.

[tezcane]

What about high level level categories (some are better than none), quickly some off the top of my head:

   Testing
   Model
       User
       Entities  (e.g. where entity audit can go)
   REST
   Security
   Database
   Cache
   Server Deployment
   Containers
   Config
   Other
      Put anything that doesn't fit above here

Front End
   Testing
   Mobile
      Ionic
      React
   Web
      Google Maps,
      etc.
   Other
      Put anything that doesnt fit above here   

Basically we show file/option structure, so user gets picture and explore all options... now it is list of ~100 items. No one will want to explore that using the menu or find about all the cool stuff they are missing.

[gmarziou]

@tezcane generator-jhipster-entity-audit belongs to both frontend and backend categories. I guess modules could have tags.

[tezcane]

OK, it is a rough mockup I made so we can see the structure high level then simplify it later. Just thinking out loud again, it is probably better to leave all categories high level, then you jump one level deep to see all modules under that category. So there will be one "Other" category, or if there becomes too many categories you put them under Other...

[pascalgrimaud]

We can't categorize modules because they are out of control.
Everybody can do module and can do what they want in it:

• delete all existing domain files and replace by other
• overwrite with regex
• etc

To answer to the initial question about Lombok, we can't add it to the main generator-jhipster because we have to maintain it in the future. We can't maintain something we don't like...

What I can see in a Lombok module:

• like audit module, adds a question to the end of the entity generation process
• use regex to delete getter / setter
• add lib to pom.xml or gradle file

I don't understand why people don't want to try to do a module for that.

[deepu105]

This is the exact reason we came up with modules. @codestrong @tezcane As the project team we have to make certain choices and here we choose to make maintenance burden less so that we can focus on most required features rather than spend time on stuff like Lombok which has mixed feelings among the dev community. You guys are free to build a module and support this it shouldn't be hard and I agree it will be useful for a lot of people. Even I might use if for some project. So here we make a decision not to add support for Lombok and as project maintainers I believe we have the right to do that. Its nothing personal its just about feature usefulness vs maintenance burden. JHipster has grown a lot and its becoming more difficult for us to maintain it already so I wouldn't want top bloat it any further. I would even consider removing some of the options like Cassandra, Session clustering etc to modules at some point if entire team agrees.

[tezcane]

I fully support you guys and know you'll make the right decisions. Thanks all for clarifying on what Modules purpose and capabilities are. I had not been able to figure this out before even though I read many modules and even "loaded" them. I read all the module docs (including how to generating one) at the time too. I feel really happy about this feature now and maybe will write a couple now. I am impartial on lombok, have not used it before. You guys are doing an amazing job, let's keep it up! This project is truly remarkable. My hats off to you.

I still think it is possible to categories the modules, we can edit any code we want in the project so adding some tagging mechanism should be do-able, right? THERE ARE NO LIMITS in software.