Generator-jhipster: [new feature] Provide configuration storage for sub-generators

[jdubois]

At the moment we store two kinds of configurations:

• The main application configuration, in .yo-rc.json, which is the standard Yeoman configuration store
• In .jhipster, the configurations from our generated entities - this isn't a standard Yeoman configuration mechanism, but it works the same way (it's just a JSON dump of the configuration object).

I would also like to store configuration data from all sub-generators, using the standard Yeoman .yo-rc.json file. Let me explain with an example, using the ci-cd sub-generator (as this is my current issue, but this is good for all sub-generators):

• Store its configuration in .yo-rc.json using the ci-cd key (use the name of the sub-generator).
• This allows to regenerate without asking the questions again: for this, I would like to use the --regenerate flag, which we already use for regenerating entities

This would have the following benefits:

• Being able to regenerate all sub-generators without asking questions again.
• Being able to quickly audit/understand the configuration. This would be helpful for bug reports, for example, as it is already the case with the main generator.
• And my current goal: generating the .yo-rc.json using a Web form, like on https://start.jhipster.tech/ , so we could run the sub-generators without any prompts (which are blocking me from running them without a command line).

[MathieuAA]

From this, it could be possible to re-create entire apps from config files to be played/replayed (and shared/stored):

• app .yo-rc.json
• entity °1...
• entity °2...
• ...
• entity °n...
• ci-cd ...

And I foresee some more uses for the JDL...

[jdubois]

@MathieuAA totally. And if you look at the new https://start.jhipster.tech (which I just published 10 seconds ago), you'll quickly see my goal :-)

[MathieuAA]

@jdubois 10 seconds ago. I'm not that quick =)

---

update: nice!!

[antarus]

It would be nice to also be able to save configuration of 'external' modules (entity audit, cloud-stream,...) ;)

[PierreBesson]

As far as I know, options are already saved in the .yo-rc.json for example for the docker-compose subgen, it's just that they are only taken into account for pre-selecting previous choices.

Maybe, we can replace those JSON files by JDL files since the JDL will soon support generating apps @MathieuAA.

[MathieuAA]

@PierreBesson my plan:

• [The first set] finish the JDL parsing with the new parsing system (more testable, modulable, and anyone can change it!)
• [First short break] have JDL and *.json file live side by side for a moment (no overlapping)
• [The second set] replace increasingly more code from the generator by what JCore already has (namely option & their values, types, logic code used by the JDL, the generator and even JUML, etc.)
• [The last set, no break] move away from the *.json files as default dumps.

For now, let's keep the JSON files where they are, and slowly as the plan goes make JDL the primary exported format (the JSON would then be dumped for debug/troubleshooting purposes).

[deepu105]

@MathieuAA we do think alike. One of the things I had in mind when coming up with the JDL grammar for application generation is that one day we will use JDL as the configuration file for JHipster. My idea was to replace .yo-rc.json and .jhipster/* files in favor of a single JDL file that declares application options and entity configurations and maybe even sub generator options. This approach has many benefits of course, like,

• Only one layer of config file to parse, store and reproduce
• Less dependency on Yeoman itself, this will help us to be more independent
• Easier for people to model an app using JDL download it and just run jhipster to create the app.
• No need to export JDL as it will be kept update always when adding entity, options etc
• Remove a lot of code that we use now for managing the JSONs and just use JH core functions to manage JDL

I like your planned roadmap as well

[jdubois]

Yes @MathieuAA , and that also allows us to have something we have planned and designed correctly.

For the record, I never thought we could do a "memory dump" of the configuration to JSON files, that was a contribution (from someone really smarter than me!!). But the result is that the JSON files are just "memory dumps", and are not well designed.

However, there are some good things about them:

• it's very easy to create a JSON document from an Angular form, and that's what the main https://start.jhipster.tech/ generator does.
• it's also easy to parse and modify, both in JS and in Java.

[jdubois]

• I'm closing this as we all agree on the issue, and my main point was that I wanted everyone to know about this limitation I just found out
• This will be solved in the future with @MathieuAA
• The only thing that is blocking me at the moment for https://start.jhipster.tech is auto-configuration Travis with the ci-cd sub-generator, I'll add a specific flag for this