search

jhipster / generator-jhipster

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
https://www.jhipster.tech
Apache License 2.0
21.54k stars 4.02k forks source link

JDL centric configurations #8915

Closed deepu105 closed 11 months ago

deepu105 commented 5 years ago

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

gmarziou commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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, notifications@github.com 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 commented 5 years ago

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

deepu105 commented 5 years ago

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 notifications@github.com 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 commented 5 years ago

descoping from v6 for now

MathieuAA commented 5 years ago

@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 commented 5 years ago

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

MathieuAA commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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:

deepu105 commented 5 years ago

@MathieuAA are you working on this?

MathieuAA commented 5 years ago

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

alfredorueda commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 notifications@github.com 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 commented 4 years ago

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

deepu105 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

@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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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:

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

yelhouti commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

It's time for an update.

github-actions[bot] commented 4 years ago

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

DanielFran commented 1 year ago

@mshima @mraible should we include this for v8?

mshima commented 1 year ago

I think it’s possible to implement if we reduce the goals to point 3 only. Use jdl as a configuration storage replacing .yo-rc.json and entities from .jhipster folder. (optionally) .yo-rc.json would still exist to store the jdl file name and baseName, since jdl can have multiples applications. Maybe we can keep secrets and timestamps at .yo-rc.json too.

This is becoming possible due to lot of internal changes:

Not sure how workpaces/multiple applications would work.

DanielFran commented 11 months ago

@mshima What is the current status on this?

mshima commented 11 months ago

I have an idea on how to implement, I will probably take a look soon.