Allow custom annotations

murdos commented 5 years ago

Overview of the feature request

Allow custom annotations for metadata/options not handled directly by generator-jhipster. E.g. :

@myFeature(parameterValue)
entity A

or

@customAnnotation(myFeature, parameterValue)
entity A

Motivation for or Use Case

It would be nice - and even required if we go to the path of JDL centric configurations - to allow custom annotations for special features added by modules or blueprints.

If you take the example of https://github.com/hipster-labs/generator-jhipster-entity-audit if add a "enableEntityAudit": true to the Entity.json file. You currently have to use the jhipster CLI or edit manually Entity.json to enable it.

This can also be very useful for blueprint: by allowing additional specific metadata, the blueprint will be able to make special decision. E.g.: not generate REST API for an entity, ...

Related issues or PR

[x] Checking this box is mandatory (this is just to show you read everything)

MathieuAA commented 5 years ago

Hi @murdos! Yep, that's clearly something we must have. I prefer the second option, as it tells that the annotation is not "standard".

However, telling how it will look in the JDL is no big deal. The real issue is to design how it will look in the JDL object (an entity, field, etc.) and the JSON

JDL part

The implementation is quite simple. Currently there are JDL options (and annotations are options, unary & binary):

Unary like client-side code generation skipping
Binary like DTO or pagination

So there should be one custom unary option & one custom binary option that:

Aren't validated (we don't check whether the option's name is standard, unless it's directly added to the generator)
- The subgen/blueprint/whatever must deal with them
  - If they are absent
  - If the values are wrong
  - etc.
Are stored the same way they are written

As for field, enum or even relationship options: relationships have options (naively and simply stored as a Set), inside them. They will have to be separated, just like JDL entity options are (that's work on my end).

JSON part

If we keep the dumped JSONs files. With the options in:

{
  "name": "EntityA",
  "...": "...",
  "fields": [
    {
      "name": "fieldA",
      "options": {
        "option1": "value1"
      }
    }
  ],
  "relationships": [
    {
      "current keys": "...",
      "options": {
        "option1": "value1"
      }
    }
  ],
  "dto": "whatever",
  "other option": "..."
}

Now what I want:

{
  "name": "EntityA",
  "...": "...",
  "fields": [
    {
      "name": "fieldA",
      "options": {
        "option1": "value1"
      }
    }
  ],
  "relationships": [
    {
      "current keys": "...",
      "options": {
        "option1": "value1"
      }
    }
  ],
  "options": {
    "dto": "mapstruct"
  }
}

with wrapped options.

murdos commented 5 years ago

How about having the first option, but use a special prefix to identify custom annotation from standard annotations: @_myFeature or @X:myFeature? With the second option we have a big difference in syntax between custom annotations and standard annotations.

Do you think that you'll be able to work on this feature? I think it's really important for the module and blueprint ecosystem. For e.g. currently using generator-jhipster-entity-audit and JDL is not possible, since generator-jhipster-entity-audit can only set its option from CLI and importing JDL overrides and erases this option.

MathieuAA commented 5 years ago

@murdos Hi, I don't like the syntax, it makes annotations (which are ugly by default) uglier. I liked the @custom() idea though

I don't know when I'll work on it, I'm rewriting the JDL import subgen, and it's a pain in the ass.

yelhouti commented 5 years ago

@MathieuAA do you need any help? I need this feature so bad.

yelhouti commented 5 years ago

This is taking too long, and I really need it, any one minding me implementing it? @MathieuAA @deepu105 @jdubois @pascalgrimaud @PierreBesson ... note: Please @ any one who might be opposite to it also please answer, I don't want to start working on something this big for it to be ignored...

MathieuAA commented 5 years ago

@yelhouti hi, first of all: there are other priorities (merging this project into the generator, the linter, the export, blueprints, etc.), and we're working on this project on our free time (when we can). There's no need to ping a ton of people just for the sake of it.

If you want to work on it, by all means. I'll try to make myself available to help you if you want.

yelhouti commented 5 years ago

@MathieuAA sorry about that, I was only trying to make sure not to waste my time on something somebody else is working on (or almost finished) since I couldn't get the information (I waited 40 days before asking again). You can assign this to me if you want that to avoid this kind of problems for someone, else. Thanks a lot for offering your help, I won't hesitate if needed.

yelhouti commented 5 years ago

@MathieuAA I though we had also annotations for fields, and relationships, it turns out we don't can I add those please? I want to used in my blueprint for something like the java @Id

MathieuAA commented 5 years ago

Yep, go ahead, I'll review your PR right away

yelhouti commented 5 years ago

Maybe someone else have a little time to review this?

deepu105 commented 5 years ago

@yelhouti was the docs updated for this?

MathieuAA commented 5 years ago

@deepu105 this wasn't a minor, but a major :( We have to release v5, as there's a breaking change in the JDL

yelhouti commented 5 years ago

@deepu105 nop not really, I should maybe uodate the blueprint page, since custom annotations can only be used in custom Blueprints. Also can you point me to the doc/website source please :)

murdos commented 5 years ago

@yelhouti : custom annotations can also be useful for jhipster modules ;-)

deepu105 commented 5 years ago

Oh sorry I didn't know there was a breaking change. So I assume it needs some work on the generator as well right? In that case I would like to make another breaking change. Currently we are passing file paths everywhere instead of passing content, it would be much nicer if the API just expects JDL content so that generator can read file and pass content as it likes. Ideally I wouldn't want to do the file reading here. What do you think?

On Fri, 27 Sep 2019, 10:29 pm Aurélien Mino, notifications@github.com wrote:

@yelhouti https://github.com/yelhouti : custom annotations can also be useful for jhipster modules ;-)

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

MathieuAA commented 5 years ago

Don't worry, I've release a v5 and added changelogs for this. And agreed.

phanithinks commented 4 years ago

Hi export-jdl CMD does not export customAnnotation from entity JSON to JDL file. is there any way to achieve this ?

MathieuAA commented 4 years ago

Please do not comment on old issues. If you think there's a problem, do create a new one instead

jhipster / jhipster-core