Allow extending JDL application options from a blueprint

[PierreBesson]

See jhipster/jhipster-core#344

Overview of the feature request

Currently when using JHipster with a blueprint that extend the available application options, it is not possible to select those options when generating an app using the JDL.

JHipster should expose an API that let blueprint developers edit the available application_options, potentially extending or restricting them. Currently they are declared in jhipster-core (see jhipster-core/lib/core/jhipster/application_options.js) with no way to extend them from a blueprint.

Motivation for or Use Case

An currently failing scenario:
app.jdl

application {
  config {
    baseName vuejsApp,
    clientFramework vuejs
  }
}

When running:

jhipster -b vuejs import-jdl app.jdl

It fails with:

Error: Unknown value 'vuejs' for option 'clientFramework'.
Error while parsing applications and entities from the JDL Error: Unknown value 'vuejs' for 
option 'clientFramework'.

Related issues

#8915 JDL centric configurations

• Checking this box is mandatory (this is just to show you read everything)

[deepu105]

Since the JHipster-UML is deprecated I think this will be much easier if we merge JHipster-core into generator as Mathieu suggested earlier, we can still expose the public API from core so that people can use it directly Thanks & Regards, Deepu

…

On Fri, Jun 7, 2019 at 2:01 PM Pierre Besson ***@***.***> wrote: *Overview of the feature request* Currently when using JHipster with a blueprint that extend the available application options, it is not possible to select those options when generating an app using the JDL. JHipster should expose an API that let blueprint developers edit the available application_options, potentially extending or restricting them. Currently they are declared in jhipster-core (see jhipster-core/lib/core/jhipster/application_options.js <https://github.com/jhipster/jhipster-core/blob/master/lib/core/jhipster/application_options.js>) with no way to extend them from a blueprint. *Motivation for or Use Case* An currently failing scenario: *app.jdl* application { config { baseName vuejsApp, clientFramework vuejs } } When running: jhipster -b vuejs import-jdl app.jdl It fails with: Error: Unknown value 'vuejs' for option 'clientFramework'. Error while parsing applications and entities from the JDL Error: Unknown value 'vuejs' for option 'clientFramework'. Related issues #8915 <#8915> JDL centric configurations - Checking this box is mandatory (this is just to show you read everything) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9870?email_source=notifications&email_token=AAIOKF5XNB6LX62C6OHH2Y3PZJEX3A5CNFSM4HVWN372YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GYHQ2EQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIOKF4QJZPABBW5FLSZY4DPZJEX3ANCNFSM4HVWN37Q> .

[ksilz]

@PierreBesson Would this request also help in the following scenario:

I want to customize the generated Angular front end through a configurable blueprint. So instead of putting a config file into my jHipster project which the blueprint then reads (can it actually?), I define configuration options (such as "hideDeletion" or "detailLinkColumn") in the JDL instead.

[PierreBesson]

@deepu105 Yes I was also considering that the merging of jhipster-core should go first. Maybe we could create a separate issue for it.

[deepu105]

Yes, let's do it. Ping @MathieuAA

[MathieuAA]

I like this GH issue. I'm gonna create an issue for this.

[MathieuAA]

Oh and if you guys agree, I'll create a new project to better keep track of the related tasks

[danielpetisme]

For the dotnetcore blueprint I need to ignore some Java oriented options and in the future I would like to add new keywords. So, you have a big +1 from my part. Let me know if I can help somehow. Le sam. 8 juin 2019 à 12:38, Mathieu ABOU-AICHI <[email protected]> a écrit :

…

Oh and if you guys agree, I'll create a new project to better keep track of the related tasks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9870?email_source=notifications&email_token=AAEQ5HFRK7KWDVUGZPNGM6DPZODZFA5CNFSM4HVWN372YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHSF6Y#issuecomment-500114171>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEQ5HAJ2RY75RC542SUEELPZODZFANCNFSM4HVWN37Q> .

[MathieuAA]

@danielpetisme thanks :) I'll definitely ping you

[PierreBesson]

As a workaround to let users generate vuejs apps with the JDL, I opened a PR to jhipster-core with a workaround: jhipster/jhipster-core#338 (adding vuejs to the list of client-frameworks).

[pascalgrimaud]

@MathieuAA @mshima @PierreBesson : as it's opened for a while, does one of you start to work on this ? Should we let this ticket opened ?

[MathieuAA]

It's something that needs doing, but right now, I'm busy with another task.

[mshima]

I think we should use something like:
clientFramework vuejs:vuejs
vuejs:clientTheme foo

Every key and value with : should be ignored for now.
I am busy removing yo dependency (improving environment lookup to be selective)

[MathieuAA]

Simpler: we could not validate what the user writes in the JDL file(s) and perform a validation just before the application-generation phase in the generator.
Solution 2: each blueprint can declare a list of values that it uses, this list will be taken into account so that no error is thrown.

[PierreBesson]

@MathieuAA maybe add a --skip-jdl-validation flag as a workaround which would implement solution 1, then proceed with solution 2.

[mshima]

I have a blueprint that implements a custom config. So it would be nice to support it.
I like the idea of namespacing the config to be easy to differentiate from oficial (supported) configurations.

[MathieuAA]

@PierreBesson I like your idea. As soon as I wrap what I'm on, I can start implementing this. Unless there's someone willing to start it now of course

[mraible]

@MathieuAA You were interested in implementing this in January? Are you still interested? If not, I suggest we close this issue.

[mshima]

At least we should implement annotations at application.
This issue have taken too long already, there is no way to add a custom config for blueprints.

[github-actions]

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

[MathieuAA]

Commenting. @nicolas63's PR should fix it after some changes are done, #12975.

[MathieuAA]

And BTW, thanks @nicolas63 for proposing a PR for theses issues (which involves this one too).

[github-actions]

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

[mshima]

This is important to have.

[DanielFran]

@mshima Can you confirm this can be closed?

[mshima]

@DanielFran no, I've added support to defining jdl options outside jdl implementation, but loading logic it is still hardcoded.
There is not way to inject the options, and there is no lookup of jdl options.

Lookup should be implemented for options, config and jdl definition related to not finished #21192

[mshima]

Implemented in #23961

[deepu105]

Is this documented somewhere if not can we please add it to docs. We are having a lot of undocumented changes