Generate application from JDL

[MathieuAA]

This is a big thing, as the 2nd level cache is specified during the application's generation, and not during entity generation... But this has a direct impact on how the entity is to be generated (with or without the annotation in the Java class file). @jdubois If I'm not mistaken, if I call yo jhipster after modifying my app, it will add some new files (from hibernateCache with the no value, to the hazelcast value), but it won't remove any file if I do the opposite (could it be possible?). Do you think it's a good idea to extend the JDL to be a kind of input during app and entity generation? For instance, if I write something like:

entity A
entity B
...
entity Z
relationship OneToOne {
   ...
}

dto * with mapstruct except J, H, I, P, S, T, E, R
hibernateCache with hazelcast

Some code, somewhere (like here) could parse it, write a yo file, and call yo jhipster to generate the app, then generate the entities. I've seriously thought about that for a while, and I think the idea of having a JDL-driven application generation is kind of nice.

Of course, @jhipster/developers, I'd like your input too! It wouldn't happen for v1.0.2, of course =)

[deepu105]

It would be nice to generate an entire application with DSL but for that the current DSL syntax would need a revamp as it could get too clumsy and cryptic when the model gets bigger.

I really liked what this guy has done https://github.com/hakandilek/vagabond-uml as it feels more natural and fine grained for complex models. The current JDL syntax for entity is great but the one for relationships and other options can be improved.

If an entire app needs to be generated from JDL I would rather have a specific syntax for that rather than following the options syntax something like

application MyNewApp {
  package com.foo.bar,
  ...
}

or something similar

[MathieuAA]

I like it, it's intuitive and easy to read. Good idea!

Le 8 juillet 2016 05:11:16 GMT+02:00, Deepu K Sasidharan notifications@github.com a écrit :

It would be nice to generate an entire application with DSL but for that the current DSL syntax would need a revamp as it could get too clumsy and cryptic when the model gets bigger.

I really liked what this guy has done https://github.com/hakandilek/vagabond-uml as it feels more natural and fine grained for complex models. The current JDL syntax for entity is great but the one for relationships and other options can be improved.

If an entire app needs to be generated from JDL I would rather have a specific syntax for that rather than following the options syntax something like

application MyNewApp {
 package com.foo.bar,
 ...
}

or something similar

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jhipster/jhipster-core/issues/38#issuecomment-231265235

Mathieu ABOU-AICHI

[PierreBesson]

I really like it. This way we could generate several apps at once which would be awesome for microservices.

[deepu105]

may be we can discuss about the syntax first here and then once everyone agrees it can be added to JDL. what say @jhipster/developers ?

[MathieuAA]

Your suggestion was, and still is, good. Moreover, as it's possible to use more than one JDL file, a simple scenario would be:

• One file for the app,
• X files for the entities.

It would be a good way to encourage conventions and clean project generation.

[MathieuAA]

Update: I'll work on that after v1.2.0.

[deepu105]

But there is one problem that needs to be tackled. We need to validate the options so that people can do only supported combinations. May be i can provide some templates in jdl studio to start

Thanks & regards, Deepu

On 30 Sep 2016 19:08, "Mathieu ABOU-AICHI" notifications@github.com wrote:

Update: I'll work on that after v1.2.0.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/jhipster-core/issues/38#issuecomment-250746437, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDlF-AsQS6c6g00tNIIRex6F-k1uKtgks5qvRDngaJpZM4JHWoQ .

[MathieuAA]

Ah good idea. I guess these two tasks are linked, so let's just enumerate what needs to be done first and then actuallly do the job.

[deepu105]

I'm thinking of providing a create app button, I also wanted to do create entity and create relationship button as well but thats a different topic.

So when people click the button I can ask them to choose from a predefined list of supported combination which ill just append to the JDL and then user can just edit the values and tune as required.

On the jhipster core side we need to validate the combinations to make sure its in line with what jhipster supports. Shouldn't be hard but would be a lot of code I presume.

Thanks & regards, Deepu

On 30 Sep 2016 19:18, "Mathieu ABOU-AICHI" notifications@github.com wrote:

Ah good idea. I guess these two tasks are linked, so let's just enumerate what needs to be done first and then actuallly do the job.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/jhipster-core/issues/38#issuecomment-250748830, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDlFwoTkSAhPO92bPJiSIR3pepBrD4Jks5qvRNCgaJpZM4JHWoQ .

[MathieuAA]

I think that's what Jose would do =) An easy impl would be to use a tree.

[deepu105]

Who is Jose?

Thanks & regards, Deepu

On 30 Sep 2016 19:35, "Mathieu ABOU-AICHI" notifications@github.com wrote:

I think that's what Jose would do =) An easy impl would be to use a tree.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/jhipster-core/issues/38#issuecomment-250752810, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDlF3_tjYFkKKpSX86xLy8Ub3iEcajHks5qvRcdgaJpZM4JHWoQ .

[MathieuAA]

The guy who will make JDL plugins for IDEs, from an issue in JDL studio.

[deepu105]

Oh him. Ya it can be done for the plugin as well but I want to do it for jdl studio as well. Unfortunately i think both projects might not be able to share code due to different underlying techs

Thanks & regards, Deepu

On 30 Sep 2016 19:38, "Mathieu ABOU-AICHI" notifications@github.com wrote:

The guy who will make JDL plugins for IDEs, from an issue in JDL studio.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/jhipster-core/issues/38#issuecomment-250753512, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDlF41tiZE-_Q2cJlm2IiNJYNhH2L0Nks5qvRfIgaJpZM4JHWoQ .

[MathieuAA]

I don't know about that. You know what? Let's first finish what needs to be done, and see if we can share things a bit later. Premature opti is, apparently, the root of all evil ;)

[deepu105]

@MathieuAA agreed.

may be lets do a patch release with current bug fixes, I think few are ready. then we can work on this and do a minor release what say?

[MathieuAA]

Yes. A minor would be cool for Christophe's feature.

Le 30 septembre 2016 17:59:39 GMT+02:00, Deepu K Sasidharan notifications@github.com a écrit :

@MathieuAA agreed.

may be lets do a patch release with current bug fixes, I think few are ready. then we can work on this and do a minor release what say?

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jhipster/jhipster-core/issues/38#issuecomment-250783017

Mathieu ABOU-AICHI

Mathieu ABOU-AICHI

[jbadeau]

I was think about this very thing the other day. Some of my thoughts:

1. The jdl language could me mastered in xtext and a studio grammer generated or viseversa.
2. I very much like the approach of being able to define a complete app and/or microservixe on jdl
3. It would be nice if the cli commands resulted in a jdl file.
4. Was playing around last night and realized we can use the jdl-studio renderer in eclipse, we dont need to build another one.
5. I think deepu105 is right that the option validation logic should be in the core but it could probably be written in a reusable form so that the studio and ide could use it

[MathieuAA]

@jbadeau Great minds think alike! Another thing I had in mind is some kind of versioning feature. Take Liquibase for instance, we can replay every change from one point to another with it. Having this kind of use for the JDL is something I'd like to see (and make happen) in the near future (point 3). I have a question, can we move objects (relationships, classes) around in the IDE version and edit them (didn't yet have time to play around)? I don't know if it's only a renderer or else.

[jbadeau]

Currently its render only as it was fast but we are aware people might like to edit via the diagrams. The jdl studio has a nice looking renderer and it would be nice to reuse it if we can. I am currently involved in another dsl project where we are in need of a web based diagram solution so it would be great to build on the existing work put into the studio renderer. Thats all new for me. @deepu105 do u think its posdible to add edit capabilities to the studio diagram? Would be nice sit down and get your thoughts on what your plans are for the studio.

[jbadeau]

There is or was a project that generated projects based on a dsl. http://sculptorgenerator.org/documentation/advanced-tutorial. I think it was cool but too complex and too many options. I think people like jhipsters opionated view, too many options just confuses people. Still i think the project solved some of the issues of generating an app based on a dsl. Might be interesting to learn how they did sonethings.

[jbadeau]

The annotation approach of vagabond-uml is pretty elegant

[MathieuAA]

VUML introduces redundancy in the DSL, which is done by the annotations (but I agree, it's nicely done). Fortunately, if (huge if here) we make JDL do things like services, it won't be that different for us (except for the JHipster part), it just won't need annotations. The point of the project (VUML) is to have a greater level of control than what's currently available in JHipster... And I don't know if the guy behind it will get it up and running yet. I hope so anyway.

Le 7 octobre 2016 08:00:35 GMT+02:00, Jose Badeau notifications@github.com a écrit :

The annotation approach of vagabond-uml is pretty elegant

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jhipster/jhipster-core/issues/38#issuecomment-252159809

Mathieu ABOU-AICHI

[jbadeau]

Is there an issue or some place where u guys discuss the jdl grammer

[deepu105]

@jbadeau Glad you found a way to use the renderer from JDL studio in eclipse. I guess there are stuff we can use from each other. Fortunately the renderer in JDL studio is not tied to the editor hence it can be used with any editor as long as you pass the json object to it. I really loved the feature set @cbornet showed on vscode and would love to have it in JDL studio, I'm ok to change editor if required and then I can style the shit out of it if needed anyway. vagabond is a fork of ours but yes I loved the annotation approach but unfortunately @MathieuAA doesnt seem to like annotations 😈 tried convincing him few times already 😉

So here are my current plans/thoughts for JDL studio cc @jhipster/developers

1) I wanted the diagrams to be editable, in fact my first iteration of JDL studio(not published) was based on plant UML, then I moved to SVG based Impl(here is a POC) so that I can drag drop stuff but it was becoming too complex and time consuming(especially the layout engine) so I decided to do a non editable version with nomnoml first (its canvas based and hence tough to edit). I would love to make it editable but would require lot of work, here is the idea I had in mind

• use the current layout engine as it good (dagre) may be update to latest version which has some breaking changes
• switch to svg based renderer (nomnoml has support for this, but we might have to fork and make some changes to make it work with JDL studio, else build our own svg render engine)
• customize the render engine to support drag/drop, linking etc, so that you can edit the layout visually
• currently flow is one way from editor to layout engine (dagre) to renderer (canvas), we would need a 2 way flow so that layout changes can update editor content as well

If anyone has a different/better idea let me know

2) Support templates for app, entity, relationships etc (I was thinking of floating buttons in editor to do that, but after seeing the idea @cbornet did for vscode I would prefer that)

3) build entire stack using JDL

create apps using template, may bit more simplified then JHipster cli, provide predefined combinations

application <AppName> {
  type monolith|microservice|gateway|uaa
  package foo.bar.app
  authentication session|jwt|oauth
  devDatabaseType mysql|posgres|oracle|maradb|mongo|cassandra
  prodDatabaseType mysql|posgres|oracle|maradb|mongo|cassandra
  hibernateCache hazelcast|ehcache
  options clusteredHttpSession, enableTranslation, websocket, sass, searchEngine, socialSignIn // add options that are required only
  buildTool maven|gradle
  testFrameworks gatling, protractor
}

now peoplecan either have a single JDL with app and entities or multiple with one file for each entity, its upto them

4) (This is huge and something most might not agree) Switch from current entity.json to entity.jdl we already have support for jdl to json and json to JDL, so we can just cut the middleman and save entity config as JDL when created from the cli inside the .jhipster folder. But this would require some changes to be clear and more readable (@MathieuAA wouldnt like this) I would propose the below template for entity.jdl

@Options(
  fluentMethods, 
  dto: mapstruct,
  pagination: pager,
  changelogDate: 20150805124838
)
entity <MyEntity(table_name)> {
  foo string required, minlength(5)
  bar integer
  ...
  @OneToMany
  anotherEntity(field_name) AnotherEntity required
}

the other entity file will look like

@Options(
  fluentMethods, 
  dto: mapstruct,
  pagination: pager,
  changelogDate: 20150805124838
)
entity <AnotherEntity(table_name)> {
  foo string required, minlength(5)
  bar integer
  ...
  @ManyToOne
  myEntity(field_name) MyEntity
}

this way we can have a single file representing an entity contract (I know its possible without annotations as well, but I just love them 😉 and of course I'm not proposing to drop current format, Im just proposing to add support for fine grained control at per entity level as well

TL;DR now with all this just imagine creating a complex microservice stack just using JDL

[MathieuAA]

That's what I want Deepu =) but replacing JSON by the JDL does not seem wise. They can live together.

Le 7 octobre 2016 08:53:19 GMT+02:00, Deepu K Sasidharan notifications@github.com a écrit :

@jbadeau Glad you found a way to use the renderer from JDL studio in eclipse. I guess there are stuff we can use from each other. Fortunately the renderer in JDL studio is not tied to the editor hence it can be used with any editor as long as you pass the json object to it. I really loved the feature set @cbornet showed on vscode and would love to have it in JDL studio, I'm ok to change editor if required and then I can style the shit out of it if needed anyway. vagabond is a fork of ours but yes I loved the annotation approach but unfortunately @MathieuAA doesnt seem to like annotations 😈 tried convincing him few times already 😉

So here are my current plans/thoughts for JDL studio cc @jhipster/developers

1) I wanted the diagrams to be editable, in fact my first iteration of JDL studio(not published) was based on plant UML, then I moved to SVG based Impl(here is a POC) so that I can drag drop stuff but it was becoming too complex and time consuming(especially the layout engine) so I decided to do a non editable version with nomnoml first (its canvas based and hence tough to edit). I would love to make it editable but would require lot of work, here is the idea I had in mind

• use the current layout engine as it good (dagre) may be update to latest version which has some breaking changes
• switch to svg based renderer (nomnoml has support for this, but we might have to fork and make some changes to make it work with JDL studio, else build our own svg render engine)
• customize the render engine to support drag/drop, linking etc, so that you can edit the layout visually
• currently flow is one way from editor to layout engine (dagre) to renderer (canvas), we would need a 2 way flow so that layout changes can update editor content as well

If anyone has a different/better idea let me know

2) Support templates for app, entity, relationships etc (I was thinking of floating buttons in editor to do that, but after seeing the idea @cbornet did for vscode I would prefer that)

3) build entire stack using JDL

create apps using template, may bit more simplified then JHipster cli, provide predefined combinations

application <AppName> {
 type monolith|microservice|gateway|uaa
 package foo.bar.app
 authentication session|jwt|oauth
 devDatabaseType mysql|posgres|oracle|maradb|mongo|cassandra
 prodDatabaseType mysql|posgres|oracle|maradb|mongo|cassandra
 hibernateCache hazelcast|ehcache
options clusteredHttpSession, enableTranslation, websocket, sass,
searchEngine, socialSignIn // add options that are required only
 buildTool maven|gradle
 testFrameworks gatling, protractor
}

now peoplecan either have a single JDL with app and entities or multiple with one file for each entity, its upto them

4) (This is huge and something most might not agree) Switch from current entity.json to entity.jdl we already have support for jdl to json and json to JDL, so we can just cut the middleman and save entity config as JDL when created from the cli inside the .jhipster folder. But this would require some changes to be clear and more readable (@MathieuAA wouldnt like this) I would propose the below template for entity.jdl

@Options(
 fluentMethods, 
 dto: mapstruct,
 pagination: pager,
 changelogDate: 20150805124838
)
entity <MyEntity(table_name)> {
 foo string required, minlength(5)
 bar integer
 ...
 @OneToMany
 anotherEntity(field_name) AnotherEntity required
}

the other entity file will look like

@Options(
 fluentMethods, 
 dto: mapstruct,
 pagination: pager,
 changelogDate: 20150805124838
)
entity <AnotherEntity(table_name)> {
 foo string required, minlength(5)
 bar integer
 ...
 @ManyToOne
 myEntity(field_name) MyEntity
}

this way we can have a single file representing an entity contract (I know its possible without annotations as well, but I just love them 😉 and of course I'm not proposing to drop current format, Im just proposing to add support for fine grained control at per entity level as well

TL;DR now with all this just imagine creating a complex microservice stack just using JDL

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jhipster/jhipster-core/issues/38#issuecomment-252166672

Mathieu ABOU-AICHI

[cbornet]

I also like the annotation syntax for options but I'm maybe too biased by my Java background... I would even propose something like

@Dto
@Pagination(pager)
@FluentMethods(false)
entity <MyEntity(table_name)> {
  foo string required, minlength(5)
  bar integer
}

As for the relationships, I like the fact that they are described outside of the entities. It makes it easier to figure the full nature of the relationship and not only one side of it. It's also easier to hint the user on what type of relationships he can define (for instance, unidirectional OneToMany is not proposed in the snippets because it's not supported).

[deepu105]

@cbornet I was also thinking of syntax similar to yours, but was then trying to reduce number of annotations to support :) For relationships yes, I do like current way of doing it, what I proposed is just an additional syntax sugar which would be easier to understand for people from Java background who are new to JDL but knows JPA

[MathieuAA]

I will create (today or tomorrow) two projects for this repo:

• Grammar improvement,
• Application generation from JDL.

We will be able to discuss these kinds of things in separate threads, and write down what needs to be done.

[deepu105]

Also we need to see if the grammer for the IDE project can be used from this repo instead of writing again there. Not sure if feasible but worth a try

Thanks & regards, Deepu

On 7 Oct 2016 13:59, "Mathieu ABOU-AICHI" notifications@github.com wrote:

I will create (today or tomorrow) two projects for this repo:

• Grammar improvement,
• Application generation from JDL.

We will be able to discuss these kind of things in separate threads, and write down what needs to be done.

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

[MathieuAA]

I doubt it. PegJS uses its own syntax. Converting it might do the trick, but I'm not sure at all.

Le 7 octobre 2016 11:47:23 GMT+02:00, Deepu K Sasidharan notifications@github.com a écrit :

Also we need to see if the grammer for the IDE project can be used from this repo instead of writing again there. Not sure if feasible but worth a try

Thanks & regards, Deepu

On 7 Oct 2016 13:59, "Mathieu ABOU-AICHI" notifications@github.com wrote:

I will create (today or tomorrow) two projects for this repo:

• Grammar improvement,
• Application generation from JDL.

We will be able to discuss these kind of things in separate threads, and write down what needs to be done.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

https://github.com/jhipster/jhipster-core/issues/38#issuecomment-252182499, or mute the thread

https://github.com/notifications/unsubscribe-auth/ABDlF0HNLyggbuRtrEDSR_9EPUKNO0EIks5qxgMGgaJpZM4JHWoQ .

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jhipster/jhipster-core/issues/38#issuecomment-252199372

Mathieu ABOU-AICHI

[jbadeau]

xtext is very good at generating other grammers xtext => PegJS but it looks complex

[jbadeau]

ecore is also able to serialize into many formats XMI,JSON,XML ...

[jbadeau]

@colameo check out the part the diagram. GEF4 maybe? or some SVG?

[colameo]

...hm, interesting discussions going on here ;-)

Personally I would separate concepts and having different DSLs each related to its own specific domain ("domain specific" ;-)).

An entity model should allow users to model only entities. Service related stuff should be made in a separate DSL, which of course can also refer to an entity model. Even options and configurations for generators (and other features) can be defined with DSLs.

With Xtext it's also possible to refer to existing models, artifacts or even java code (there are no restriction to that).

Finally, if you are thinking to improve the existing web based JDL studio or even have one grammar for IDE and JDL studio, why not use the new web JDL editor in our project as a base: https://github.com/jhipster/jhipster-ide/tree/master/io.github.jhipster.jdl.web

[deepu105]

@colameo this cannot be used as it is without the visual layout, thats the main reason I wrote JDL studio. As I said I'm ok to switch the editor alone as long as its feasible. Also note that current JDL studio is just a client only app there is no server running. That means there should be a way to get static assets from the IDE project. If thats possible I can see if I can replace the codemirror editor with this. I havent looked into the IDE repo code yet. So forgive me if I sound naive

[colameo]

@deepu105 a visual component to the web editor could be added similar to the plantuml integration in the IDE project. Xtext generates from the grammar an EMF model which represents the AST of a lang. We usually use this (Ecore) model to write generators or interpreters. Have a look to the plantuml renderer which actually acts as an interpreter and produces from the JDL AST model a plantuml document.

[deepu105]

But how are you proposing to serve it, I guess it would require a dedicated server doesnt it?

Thanks & Regards, Deepu

On Fri, Oct 7, 2016 at 10:43 PM, Serano Colameo notifications@github.com wrote:

@deepu105 https://github.com/deepu105 a visual component to the web editor could be added similar to the plantuml integration in the IDE project. Xtext generates from the grammar an EMF model which represents the AST of a lang. We usually use this (Ecore) model to write generators or interpreters. Have a look to the plantuml renderer https://github.com/jhipster/jhipster-ide/blob/master/io.github.jhipster.jdl.ide/src/io/github/jhipster/jdl/ide/renderer/plantuml/JdlToPlantUmlRenderer.xtend which actually acts as an interpreter and produces from the JDL AST model a plantuml document.

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

[colameo]

Yes, that's true... what about building a docker image? Most developers have anyway docker installed on their machine, so shouldn't be a problem (I guess ;-)).

[jbadeau]

Is there a jhipster slack channel for developers?

[jbadeau]

Correct me if im wrong but if eclipse or intellij ... are running then the broeser can talk to it. Could evennuse the embedded browser to put it in the ide?

[MathieuAA]

Ok guys, I've created two projects. One is "Grammar Improvement", and the other is "Application Generation - JDL". I've also added READMEs so as to be precise and clear about things, feel free to contribute! Now the tricky part (open to suggestions): when contributing to project 1 or project 2, use the branches "project/grammar_improvement" or "project/app_generation". If you want, we can lock the master branch for regular things (small updates, bug fixes, and so on)... everything except work on the projects either go to master or a separate branch (depending of the work, of course). Now, I know both projects won't be worked on at the same time (would be nice though) but anyone's free to contribute to everything (even if already contributing to the other project).

Anyone can create tickets in the projects' board, and it would be really nice if each ticket is linked to an issue.

Finally, ideas are welcome =)

ps: @deepu105, and you can quote me on this, I'm ok with "annotations", as long as they don't have "@" :).

[jbadeau]

@deepu105 @jhipster/developers

1. I think that in the long run maintaining 2 grammers (xtext & PegJS) will be expensive, especially as the language evolves with more features. I think as Xtext supports eclipse, intellij, web and LPS environments (vscode, che, redhat) it is prob the best option.
2. I myself am very very interested to work with @deepu105 on the editable diagram support. There are so many diagram fameworks. I really like the philosophy of http://jankoehnlein.github.io/FXDiagram but im not a fan of plugins and i doubt modern browsers support it. so HTML5 or canvas I guess
3. I also don't see why JDL and json can't live together but I get that single sourcing would be nice
4. I also would like to see more features in JDL as well as better structure. Looking forward to work on this too.

[MathieuAA]

I don't see how to use the Xtext grammar in this project. If I'm missing something, please do tell me... Using PegJS is not a bad thing as it does the job pretty easily (even if the parser is ugly as hell). However, converting one form of grammar to another seems like a good but difficult to implement idea... The irony of it is that one could make a PegJS grammar to convert the grammar from this project to the Xtext grammar you guys have ;)

[deepu105]

@colameo @jbadeau The idea of JDL studio is to have a simple web app to visualize entity creation for real world projects, so we really cannot ask people have docker or IDE open for it to work, which IMO is very bad user experience. And I dont see any advantage here as well, the only thing I'm interested in is the stuff shown in vscode extension (which if required I can build in JDL studio as well) otherwise JDL studio used grammer and parser from Jhispter-core anyway so there is no problem here. So lets leave the web version as it is. the real need would be to find a way to have the parser/grammer in one place and I would prefer that place to be jhipster-core if possible. If thats difficult we should think of writing a converter to get the language to IDE project without having to write both seperately

@jbadeau I have a slack channel for JHipster but nobody is using it. There is also a gitter channel https://jhipster.slack.com/messages/general/ https://gitter.im/jhipster

@jbadeau regarding your comment for editable diagram we need to go for SVG based renderer

@MathieuAA I dont understand why you hate @ so much anyways 😉 but annotations without @ is confusing since we are used to that in java, typescript etc and it would be against UX principals as well

[colameo]

As long as every change in the JDL structure is documented (JDL examples would be enough) we can make sure to keep the IDE project compatible. This would be for me the best feasible way to keep both projects in sync. Xtext has many "special" grammar concepts which will be quite difficult to maintain in a PegJS-to-Xtext transformer. Vice versa could be possible (e.g. Xtext generates ANTLR grammar), but of course it would take more time than just maintain manually the new JDL features in the IDE project. I've copied yesterday all JDL test files from jhipster-core in our testing project and implemented a test case which reads those JDL files and executes validations. So again, from my point of view the best way to implement new lang features is to write down JDL files and use as much as possible test cases.

[MathieuAA]

@colameo Got it. Tell me if you need anything.

[MathieuAA]

I'm closing this, a more recent post exists about improving the JDL.