Generator-jhipster: JDL centric configurations

[deepu105]

Based on discussions here this ticket is to implement the JDL centric features described below

JDL Centric approach.

When the app JDL and JDL app microservice support was released we can clearly see people using that a lot and is much easier to use than the CLI approach. The CLI approach still has merits but the user experience of JDL beats that. To truly make it more effective I propose the below

• [X] Merge Jhipster-core into generator

• [ ] Enhance JDL grammar a bit more see https://github.com/jhipster/jhipster-core/issues/277

• [ ] Save application and entity configuration as JDL instead of .yo-rc.json and .jhipster/*.json. Keep backward compatibility for v6 and become JDL only in v7

  • This will help to remove some code in syncing these up and will have more freedom as we have control over JDL
  • This will make sharing applications and recreating them much easier.
  • You can import applications with ease.
  • We already have most of the bits and pieces to do this in place and is not a major change to do.
  • you can look at the JDL for an app and get an overview of the application, entities, service, and deployments.
  • working with JDL is more visual than working with CLI and you can iterate faster
• [ ] deprecate some of the CLI commands like entity and support only import-jdl as its more practical and easy for us to maintain
• [ ] save secrets in a separate gitignored file like secrets.jh or jhipster.secrets

[gmarziou]

save secrets in a separate gitignored file like secrets.jh or jhipster.secrets

Which secrets? dev and/or prod ?
In my opinion JHipster should not generate any prod secrets even if we warn users about changing them.

[deepu105]

@gmarziou definitely not prod, just the jwtSecretKey, rememberKey and admin password used for registry in deployments(stuff that we already generate and persist in yo-rc files). Users will still have to change them for prod

[jdubois]

As JHipster 6 should be released soon, I don't think this issue can be done in the meantime: @deepu105 are you OK to remove the JHipster 6 milestone here, so we do it later?

[deepu105]

I'm bit hold up due to my recent home shift etc, but let me see what I can
do next week. Leave it open for now I'll close it if I can't work on it
next week

On Wed, 27 Feb 2019, 5:58 pm Julien Dubois, [e-mail]
wrote:

As JHipster 6 should be released soon, I don't think this issue can be
done in the meantime: @deepu105 https://github.com/deepu105 are you OK
to remove the JHipster 6 milestone here, so we do it later?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8915#issuecomment-467943056,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlFy2BbAmnFIeN9IhealetV-Gjh8RDks5vRrkkgaJpZM4Y8_DM
.

[MathieuAA]

If you can't work on it, tell me. I'm wrapping up the linter and will have some free time.

[deepu105]

Let me try this week, If I don't find time I'll ping you

Thanks & Regards,
Deepu

On Tue, Mar 5, 2019 at 4:37 PM Mathieu ABOU-AICHI [e-mail]
wrote:

If you can't work on it, tell me. I'm wrapping up the linter and will have
some free time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8915#issuecomment-469727178,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF88MDfOgJxJRMmYjOnzMXk2PsXw2ks5vTo9GgaJpZM4Y8_DM
.

[deepu105]

descoping from v6 for now

[MathieuAA]

@jhipster/developers I don't see it happening without issues unless we merge the JCore dep into this repo., because of the foreseeable issues of not having a "monorepo".
We could keep JCore as a dependency for other projects (because it exposes some useful JHipster-related notions), and remove it as a dependency from this project.
The only con I see is that issues from JCore could "pollute" this project's issue tracker. I don't think I need tell list all the pros, there are too many :)

[pascalgrimaud]

It needed to be discussed seriously in the mailing list as it will be a major change

[MathieuAA]

@pascalgrimaud I personally prefer this kind of communication, as it's more transparent and visible (I guess that's a matter of opinion). But I'll drop a mail in the mailing list today.

[pascalgrimaud]

@MathieuAA : agree, I prefer the discussion here, but we need to inform by mail the other member there is an important discussion here. We have too much GitHub notifications, so they'll miss this important one :)

[yelhouti]

Hi devs, I rely a lot on JHipster and try to contribute/share my opinion as much as I can. I thank you for the great work.
For these very important discussions, I think you should let people from outside the core-team participate (mailing list is private if I'm not wrong), until that's the case, I'll leave my opinions (FWIW) here:

• I love the Idea about a JDL centric approach.
• I'm not a big fun of the side by side code, in my projects I have a jdl-import branch where the only thing done is update the jdl upgrade and import, I then merge it into master. I also would prefer that upgrade doesn't create it's own branch (since I'm already doing that manually). I think this approach should be documented as IDEs often have a resolve conflict GUI that make this process much easier than described.
• I would also love to have the ability to use multiple blueprints. one for the frontend, another for the backend, one that only edit the some configs..., this would allow to share blueprints that do not contain very specific code.
• For the JDL approach to work for everyone I think that this feature request is a must have, and I'm glad @MathieuAA is planning to work on it: https://github.com/jhipster/jhipster-core/issues/320

[deepu105]

@MathieuAA are you working on this?

[MathieuAA]

@deepu105 not at the moment no. I've got some things that need taken care of (linter, v4, etc.).

[alfredorueda]

Just from a user perspective (I use and love JHipster since 2014), I really prefer JDL over CLI, because of the reasons exposed earlier.

You can import applications with ease.
You can look at the JDL for an app and get an overview of the application, entities, service, and deployments.
Working with JDL is more visual than working with CLI and you can iterate faster

[deepu105]

@MathieuAA lets start this by merging JHipster-core into the main project. I think most of the core team agreed to that. @jhipster/developers do anyone have any objection to merging jhipster-core into generator-jhipster?

[PierreBesson]

@deepu105, as this feature is quite complex, maybe you can create an RFC linked to this issue as described in https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md

[deepu105]

Ya sure, I'll move it when I have some time

Thanks & Regards,
Deepu

On Thu, Jul 4, 2019 at 10:44 PM Pierre Besson [e-mail]
wrote:

@deepu105 https://github.com/deepu105, as this feature is quite
complex, maybe you can create an RFC linked to this issue as described in
https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8915?email_source=notifications&email_token=AAIOKF7WHPGGCHPTSSJSURTP5ZOKPA5CNFSM4GHT6DGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZIDOXY#issuecomment-508573535,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIOKF4WPIVDFEHFJRPR6MLP5ZOKPANCNFSM4GHT6DGA
.

[pascalgrimaud]

This ticket is opened for a while too, and it looks like a lot of work.
Does someone have time to start this ?

[deepu105]

I wan't to, may be I'll have time next month

Thanks & Regards,
Deepu

On Tue, Jan 28, 2020 at 9:09 AM Pascal Grimaud [e-mail]
wrote:

This ticket is opened for a while too, and it looks like a lot of work.
Does someone have time to start this ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8915?email_source=notifications&email_token=AAIOKF23GFOKYY7P6IRIWXDQ77RZZA5CNFSM4GHT6DGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKCMUFA#issuecomment-579127828,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOKF6THORDTPHVK3P6UITQ77RZZANCNFSM4GHT6DGA
.

[mshima]

Since v6 goals have been postponed to v7.
Then jdl only is postponed to v8 correct?

I don’t understand the reason to eliminate .yo-rc completely.

[MathieuAA]

@mshima the main reason is that it's easier to read a JDL file than a dumped JSON one.
However, this "feature" can be split:

• the first step being an automatic JDL export/update of entities & apps when creating/updating apps & entities
• the final step being the removal

If even the first step is hard to do (which isn't really as the JDL export is already implemented) or there are more important tasks, then I suggest this feature be postponed.

[yelhouti]

Adding a note here to take into consideration if possible:
the way entity data is loaded today, each config is loaded one by one. In the case of blueprints that wants to handle composite keys, you need information about the other entity to create an entity file, it would be great to have a global var with all the entities that all of them can access, not I use a dirty hack that reads the json and recomputes for each "dependency"

[MathieuAA]

Hello @yelhouti. If I get this correctly, when one imports a JDL content, there's a need for all entities to be listed "globally" in the generator when importing them, right?
The JDL importer returns a state of everything that has been parsed (and could be imported): entities, applications, deployments.

[yelhouti]

@MathieuAA indeed, the way it works today is that the this variable contains the context of the entity with the fields, relationships... this content is read using getEntityJson at the start of each entity to generate.
Ideally, before, starting the generation of entities, all contexts should be loaded into memory, and I would have a hook to populate my own options... (compute primary keys...)

[yelhouti]

@MathieuAA I can make a PR if you don't mind that does all this, if you can merge it for me, it's a lot of work, so I prefer to ask before coding. This would allow multiple blueprints that needs the same variables to share code.

[mshima]

@MathieuAA I can make a PR if you don't mind that does all this, if you can merge it for me, it's a lot of work, so I prefer to ask before coding. This would allow multiple blueprints that needs the same variables to share code.

@yelhouti I don't think you should waste time with this right now.
This is a very complicated issue and should be changed a lot once v7 windows is open.
There is a lot to take into account, ex: synchronisation between the generators, mem-fs vs disk.
Loading every thing, depending on when it's loaded, will not work because everything is subject to change.
Some related issues:

• To many configuration sources (this, this.config, this.options.configOptions, this.getAllJhipsterConfig, probably others).
• https://github.com/jhipster/generator-jhipster/issues/10528.

I think you should open a new issue to track this, it's completely unrelated to jdl.

[yelhouti]

@mshima thanks for pointing me to the other issue, I would go as far as saying it's unrelated, as the JDL will be loaded at once and it would be the right time to do my changes, make one entity point to the other...
But I understand what you are saying, just trying to make sure that it will go in a direction that won't make the two blueprints I am maintaining unusable.

[mshima]

@mshima thanks for pointing me to the other issue, I would go as far as saying it's unrelated, as the JDL will be loaded at once and it would be the right time to do my changes, make one entity point to the other...
But I understand what you are saying, just trying to make sure that it will go in a direction that won't make the two blueprints I am maintaining unusable.

I have a blueprint that creates a new entity and make some of the others point to the one I've just made.

But since I support prompt too, just after jdl is parsed isn't the best place to put it.

[mshima]

It's time for an update.

• This issue proposes to drop prompt support.
  I think some of us still uses prompts, cc @pascalgrimaud.

• Proposes to drop .yo-rc.json and .jhispter/.
  IMO they are a database with current application state. Not configuration files.
  Incremental changelog uses jdl as new state, while .yo-rc.json and .jhipster/ are the old state.

• The workflow is clean now, most of the problems we had with .yo-rc.json and .jhipster/* should be fixed.

[github-actions[bot]]

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 :smiley:.
Comment or this will be closed in 7 days