manage jdl

[antarus]

hello,
@pascalgrimaud
I started a parser for the jdl (https://github.com/antarus/jdl) with antlr.

With the experience of the jdl parser in nodejs, I wanted to know if the approach was the right one or if there were things to change or take into account before rushing headlong. @MathieuAA an opinion?

Should we have a specific version of the jdl for jhipster-lite? I am not sure.

Otherwise, some ideas emerge from a first analysis of the JDL.
The concept of application could be a successive addition of specific modules and configurations in jhipster-lite.

[MathieuAA]

I'll review tomorrow :)

[antarus]

ok there is not much to review. ;D it was mainly to know if you saw things to change or to do differently.
I saw that the parser had to be rewritten in TS but I thought I would take inspiration from the existing one for the java part .

Who says rewritten say problem with the current version that I would like to avoid reproducing :D

thanks;)

[DamnClin]

Hello,

As I don't build applications around data I'm not a JDL user, and, to be honest, I don't know what it is doing. Can you explain the goal of the JDL integration in JHLite?

• Is it to generate JHipster CRUD applications? If yes what is the goal of that?
• Is it to generate infrastructure elements in an hexagonal architecture? If yes what is the goal of that?
• Is it to generate many applications from one description? If yes what is the goal of that?
• Is it something else?

Thanks in advance.

To be honest, I don't think I'll be able to help a lot on that because:

• I don't need it (so no personal motivation to contribute and no good vision);
• For now I don't understand the need for this (that may change).

[pascalgrimaud]

I think it can be usefull, as some companies loves "Data Driven"

Serious answer now: I totally agree with @DamnClin
What could be proposed is maybe only the 2nd point: infrastructure in secondary -> Entities and JpaRepository

@antarus : I suggest to discuss seriously first about this, before going too further. I don't want you to lost your time on this, unless we all agree 🙏

For your information, I manage to use generator-jhipster JDL in a project generated with JHipster Lite, I can give more details if needed

[DamnClin]

To be honest, I see value in the 3 proposal I made BUT I think it is only possible to implement 2 of them. But, again, i'm not using it so I'dd like to have answers from actual users

[antarus]

Don't worry, I'm not wasting my time too much, it allows me to get up to speed in java for September

For me the JDL is used to describe my final application.

I try not to think by the database anymore and I think that the JDL remains a very good DSL to generate an application.

It could be used initially to define the properties of the different modules.
It can generate jpa entities on the secondary side.
it can generate different code structures

it could evolve to

• define the different modules to be applied.
• generate the forms on the view side ( Separate form and entity definition generator-jhipster#19022)
• describe the domain, the VOs etc in order to generate the entities of the domain (at least their structures) possibly the associated builders
• Generate or not the associated services / repository

I will be interested in your current workflow @pascalgrimaud

[MathieuAA]

The JDL was only a solution to a need: avoid the questions of the generator. How: by proposing an alternative way to generate an app.

The question is not how we can use the JDL but whether a DSL is actually needed

[pascalgrimaud]

@antarus : here the workflow I used once, using a project generated with JH Lite:

{
  "actions": [
    {
      "module": "init",
      "date": "2022-07-28T06:15:53.861632052Z",
      "properties": {
        "projectName": "beer project",
        "baseName": "beer"
      }
    },
    {
      "module": "maven-java",
      "date": "2022-07-28T06:16:10.801385380Z",
      "properties": {
        "projectName": "beer project",
        "baseName": "beer",
        "packageName": "tech.jhipster.beer"
      }
    },
    {
      "module": "springboot",
      "date": "2022-07-28T06:19:22.553784268Z",
      "properties": {
        "projectName": "beer project",
        "baseName": "beer",
        "packageName": "tech.jhipster.beer"
      }
    },
    {
      "module": "springboot-tomcat",
      "date": "2022-07-28T06:19:38.908305238Z",
      "properties": {
        "projectName": "beer project",
        "baseName": "beer",
        "packageName": "tech.jhipster.beer",
        "serverPort": 8080
      }
    },
    {
      "module": "postgresql",
      "date": "2022-07-28T06:22:01.226414001Z",
      "properties": {
        "projectName": "beer project",
        "baseName": "beer",
        "packageName": "tech.jhipster.beer",
        "serverPort": 8080
      }
    },
    {
      "module": "liquibase",
      "date": "2022-07-28T06:22:06.464943674Z",
      "properties": {
        "projectName": "beer project",
        "baseName": "beer",
        "packageName": "tech.jhipster.beer",
        "serverPort": 8080
      }
    }
  ]
}

Then, I added a fake .yo-rc.json :

{
  "generator-jhipster": {
    "baseName": "beer",
    "databaseType": "sql",
    "devDatabaseType": "postgresql",
    "entities": [],
    "entitySuffix": "Entity",
    "lastLiquibaseTimestamp": 1657095849000,
    "packageFolder": "tech/jhipster/beer",
    "packageName": "tech.jhipster.beer",
    "prodDatabaseType": "postgresql",
    "skipClient": true
  }
}

Here a JDL:

@EntityPackage("toremove")
entity Project {
  name String
}

@EntityPackage("toremove")
entity Label {
  label String required minlength(3)
}

@EntityPackage("toremove")
entity Ticket {
  title String required
  description String
  dueDate LocalDate
  date ZonedDateTime
  status Status
  type Type
  priority Priority
}

@EntityPackage("toremove")
entity Attachment {
  name String required minlength(3)
  file Blob
}

relationship ManyToMany {
  Ticket{label(label)} to Label{ticket}
}

relationship ManyToOne {
  Ticket{project(name)} to Project
  Ticket{assignedTo(login)} to User
  Ticket{reportedBy(login)} to User
  Comment{login} to User
}

relationship OneToMany {
  Comment{parent} to Comment{child}
  Ticket to Attachment 
}

enum Status {
  OPEN("Open")
  WAITING_FOR_RESPONSE("Waiting for Customer Response")
  CLOSED("Closed")
  DUPLICATE("Duplicate")
  IN_PROGRESS("In Progress")
  REOPENED("Reopened")
  CANNOT_REPRODUCE("Cannot Reproduce")
  SOLVED("Solved")
  WONT_IMPLEMENT("Won't Implement")
  VERIFIED("Verified")
  
}

enum Type {
  BUG("Bug"),
  FEATURE("Feature")
}

enum Priority {
  HIGHEST("Highest")
  HIGHER("Higher")
  HIGH("High")
  NORMAL("Normal")
  LOW("Low")
  LOWER("Lower")
  LOWERST("Lowest")
}

@EntityPackage("toremove")
entity Comment {
  date ZonedDateTime
  text String
}

paginate Ticket with pagination

Here what is generated, in the dedicated package toremove :

Then, I only keep Entity, Repository and changelog xml. All other classes are deleted
I added the missing unit tests, did some refactoring, some mappings between the domain objects and the entities, etc.

[antarus]

too complicated to put this in the jhipster generator. I prefer to do it in the lite I have already made good progress on the creation of objects from a jdl 😄

[vrecon]

Pascal, how did you create this. Do you have the code anywhere so i can try it out myself also?

[DamnClin]

Pascal is far from computer for a few days but I think he explained the process no? Once you have this you use the jdl generator from jhipster and you should end up with the same result. At which step are you struggling?

[vrecon]

sorry mist the part he used the jhipster jdl generator. Ok that makes sense. I thought he started on a port to make it also available on jhipster-lite. Same as antarus did. thnx for your reply.

[DamnClin]

No problem :) enjoy. As I already sayed, I won't do the JDL integration in JHLite (since I don't use it) but I can help with module usage or the way to generate a primary and secondary adapters (there is an example with the dummy feature)

[pascalgrimaud]

cc @jdubois about the discussion, related to JDL

[antarus]

Hello, after having used the jdl a little with the generator jhipster in hexagonal infra from jhipster-lite, the jdl is not very suitable.

For example, we cannot make a distinction between an entity and a Value Object.(I like record !)

The jdl is very database oriented with relationShip.

I would like in my jdl to be able to describe my business entities/VO, my jpa entities and my different objects, not necessarily generating all the CRUD functions

With EntityPackage we can trim the work but there is still a lot of refactoring to do.

In the end, it would take either other options in the JDL not to generate jpa entities but business model or make a DSL more suitable for jhipster-lite so that it generates it.

[antarus]

small draft for a dsl jhipster-lite for discussion: https://gist.github.com/antarus/63dd5035fa20f3277a2ebac93414299a

[jdubois]

Thanks for the hard work @antarus !!
This adds some complexity on the JDL, but I'm not sure there's another way to do this.

[antarus]

yes it is more complicated but it offers more freedom. I think there is the possibility of making it simpler or differently (we could limit ourselves to describing a crud, which will simplify a little but will limit the use)

But I can't see myself doing without a dsl so much it simplifies the launch of a project or generates boring things for me.

[antarus]

Hello,

I started creating the parser/lexer for the dsl file. You can find it here https://github.com/antarus/jhipster-lite/tree/feature/dsl

For the moment only the parsing part of the file is done, Ii think I'll start working on the generation part next week

But I admit that I still don't really know how to integrate it properly into the project :'(

[jdubois]

Wow that's really incredible work! For integrating it, I believe we need to keep the JDL Studio, so it would be a REST endpoint where we POST the JDL file, and then it's processed with your parser. The hard part is what you have done, integration doesn't seem that much complicated.

[vrecon]

Ok, I will take a look a it later. But great work!

…

Hello, I started creating the parser/lexer for the dsl file. You can find it here https://github.com/antarus/jhipster-lite/tree/feature/dsl <https://github.com/antarus/jhipster-lite/tree/feature/dsl> For the moment only the parsing part of the file is done, Ii think I'll start working on the generation part next week But I admit that I still don't really know how to integrate it properly into the project :'( — Reply to this email directly, view it on GitHub <#2754 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ65ZEP555DJEEE2LP3PFDWK6MLNANCNFSM54QCQMRQ>. You are receiving this because you commented.

[antarus]

@jdubois it's not yet crud but it's starting to generate code..

#4746

[jdubois]

Yes @antarus I would start by doing CRUD only:

• It's much easier, and will allow to migrate without any issue at it would be the same thing
• As @DamnClin says, JDL is mostly for CRUD, and doesn't make that much sense for an hexagonal architecture
• Anyway, and that was my original idea with the JDL, generating a CRUD doesn't block you from doing something better later: I wanted to have everything generated, in an easy to use package, but then you can refactor your code easily and re-organize it