Generator-jhipster: JDL application options

[rubensa]

Overview of the issue

At JDL application options documentation page:

JDL option name | Default value | Possible values | Comment
----------------------|------------------|---------------------|---------------
serviceDiscoveryType | false | eureka, consul, no |

The Default value seems to be wrong as the only accepted values are eureka, consul, no.

Motivation for or Use Case

Fix doc (and possibly implementation).

Reproduce the error

Using JHipster JDL for vscode (v. 1.3.1) shows error if using value false.

application {
  config {
    serviceDiscoveryType false
  }
}

##### **Related issues** ##### **Suggest a Fix** The easy fix should be changing the value from false to no in Doc Note: But... there seems to be some inconsistency for "don't use" value as some options use "no" and other options use "false". Default "don't use" values should be revised in order to be consistent. ##### **JHipster Version(s)** 5.5.0 ##### **JHipster configuration** Using JHipster version installed globally Executing jhipster:info Options: from-cli: true Welcome to the JHipster Information Sub-Generator ##### **JHipster Version(s)**

/media/data/rubensa/development/vscode/workspace/autotriaje/monolith
└── [email protected]

cat: no such file or directory: .yo-rc.json ##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**

.yo-rc.json file

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory

JDL entity definitions

Environment and Tools

java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

git version 2.17.1

node: v8.11.3

npm: 5.6.0

Docker version 18.06.1-ce, build e68fc7a

docker-compose version 1.21.2, build a133471

Entity configuration(s) entityName.json files generated in the .jhipster directory

Browsers and Operating System

Linux 4.15.0-36-generic Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

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

[MathieuAA]

These inconsistencies are in the generator as well, the JDL reflects those. We should do something about it, definitely.

[MathieuAA]

cc @jhipster/developers

[colameo]

@rubensa about vscode I will create an issue for you in the jhipster-ide where the extension is maintained.

[colameo]

@MathieuAA what shall we do with this? The jdl importer can already handle both values. So I may allow both inputs as valid option values in the JH IDE as well? I want to finish the 1.5 release as I fixed a couple of annoying issues...

[MathieuAA]

Allowing both is the only choice right now. I'll work on removing inconsistencies in the generator later...

[deepu105]

I think supporting both internally and cleaning up docs to support only false would be the best solution.

[murdos]

true/false are fine for every option titled enableXXX, but for the following options that are expecting multiple values, wouldn't the value none be more accurate as a canonical value? false sounds a bit strange (but I'm not a native English speaker...)

Options | Possible values
------------ | -------------
searchEngine | elasticsearch, false
serviceDiscoveryType | eureka, consul, no
messageBroker | kafka, false
prodDatabaseType | mysql, mariadb, mssql, postgresql, oracle, no
databaseType | sql, mongodb, cassandra, couchbase, no
cacheProvider | ehcache, hazelcast, infinispan, no
... | ...

[deepu105]

I agree with you and I also thought about that, but we don't want to add
another value, as it would become even more confusing and lot more
maintainance to do. So for bow lets stick to either false or no. I'll leave
the decision to Mathieu. May be we can change to none in next major version

On Sat, 20 Oct 2018, 10:53 pm Aurélien Mino, [e-mail]
wrote:

true/false are fine for every option titled enableXXX, but for the
following options that are expecting multiple values, wouldn't the value
none be more accurate as a canonical value? false sounds a bit strange
(but I'm not a native English speaker...)
Options Possible values
searchEngine elasticsearch, false
serviceDiscoveryType eureka, consul, no
messageBroker kafka, false
prodDatabaseType mysql, mariadb, mssql, postgresql, oracle, no
databaseType sql, mongodb, cassandra, couchbase, no
cacheProvider ehcache, hazelcast, infinispan, no
... ...

—
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/generator-jhipster/issues/8608#issuecomment-431617230,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF1BU54Jmcg5kEvnINUfmKb3e4JMvks5um41WgaJpZM4XvxF3
.

[colameo]

@murdos I agree as well, that in this case we want to explicitly not define a value for an option, so maybe none would be a more expressive/appropriate value for a non-boolean option type...

[deepu105]

An option would be to add a util method on jhipster-core like below and use that to compute the value for JDL and generator prompts, then update docs to just use none

const getNoneValue = value => ! ['none', 'NONE', 'no', 'NO', false].includes(value);

[colameo]

About option: testFrameworks [] would something like testFrameworks [none] not be more consistent with the other options?

[colameo]

About option: testFrameworks [] would something like testFrameworks [none] not be more consistent with the other options?

...from a language design perspective this looks like another way to specify a "do not use" option

[colameo]

An option would be to add a util method on jhipster-core like below and use that to compute the value for JDL and generator prompts, then update docs to just use none

const getNoneValue = value => ! ['none', 'NONE', 'no', 'NO', false].includes(value);

I would rather prefer one (clear) way to define an option value rather than allow different values to express the same "logic"... the implementation is not a problem (at least in the IDE). Of course it would make the logic for content assist and validation a bit more complex, but that's not the main point here.

[deepu105]

@colameo I would also prefer that but we can't do that without a breaking version so this is an interim solution for backward compatibility

[deepu105]

for content assist and docs we should stick to preferably none

[deepu105]

for v6 lets standardize everything to use 'none', the enable, disable props will continue to use true/false

we will handle no/false as a fallback but will not document it

Options | Possible values
------------ | -------------
searchEngine | elasticsearch, none
serviceDiscoveryType | eureka, consul, none
messageBroker | kafka, none
prodDatabaseType | mysql, mariadb, mssql, postgresql, oracle, none
databaseType | sql, mongodb, cassandra, couchbase, none
cacheProvider | ehcache, hazelcast, infinispan, none
... | ...

[pascalgrimaud]

It has been opened for a while.
Does someone want to work on this for the v7 ? Otherwise, let's close this and focus on other features

[rubensa]

Looks like @MathieuAA and @murdos are looking at this. See this related issue https://github.com/jhipster/jhipster-core/issues/283

[pascalgrimaud]

Only comments / discussion, there is no work on this (unless I'm wrong)
That's why I'm asking this.

[MathieuAA]

There's some work for this, but a refactor was needed to do it right. The refactor is done and ready to be merged. The next step is implementing this feature.

[PierreBesson]

@MathieuAA do you need a bounty for this feature?

[MathieuAA]

Nop, almost done! Thanks anyway

[MathieuAA]

Applications can now have options in their declaration (cc @colameo), I believe there's another issue about value standardization ('no', false, etc.) in JCore and referenced in the v7 roadmap.
What I propose is to open an issue about value standardization with the info from here and close this one

[colameo]

@MathieuAA I'm completely redesigning the option part in the JH IDE project and want to talk with you about this topic. As we already discussed last year, from my point of view we need also a workflow for language changes otherwise people will end up with incongruent behaviour in the tooling which of course confuses. I will contact you by mail.

[MathieuAA]

@avdev4j Unless you have an objection, I'm gonna add this issue to the v7 project list.

[avdev4j]

It's made to be alive along the v7 is in progress :).

Feel free to add what you think is important

[MathieuAA]

@murdos any objection if I take it?

[murdos]

@murdos any objection if I take it?

Not at all!

[MathieuAA]

There are some things we can do to improve the overall "option handling" experience:

• fix option values according to their types (what this is issue is originally about)
• use the affirmative form instead of a mix of the two (enableTranslation vs skipClient)

I'll create separate issues for the two points to detail everything. I plan to use them for JCode.

[github-actions[bot]]

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]

Reopening issue since @MathieuAA created a PR but it is yet done

[MathieuAA]

A non-breaking version can be done before breaking things, so I suggest not to keep it mandatory for v7.
Also, I fear I won't be able to make it due to the lack of time I'm facing :( so if anyone wants to tackle it, be my guest