Quarkus: Config key name casing consistency

[FroMage]

We need to:

• generate a list of the current existing config keys used,
• decide on a casing style to separate words between:
  -- camelCase
  -- snake_case
  -- brochette-case
  -- pixel.case (single words between dots)
• fix the existing config keys to adhere to the consistent style
• probably make the doc system enforce the casing by checking it so inconsistencies don't creep back

[FroMage]

Related to #511, and to the current work of @dmlloyd

[cescoffier]

I would avoid the _pixel.case_ as it can be an issue in Yaml.

[gsmet]

I think having shamrock.<extension>.<key> makes sense.

But I concur we have to have a convention for the format of <key>. I personally like dashes better for properties.

[cescoffier]

Note that some MicroProfile specification mandates . (fault-tolerance)

[emmanuelbernard]

One of the question is whether we favor the reuse of the specific library property name. Or come with our own disregarding the library to favor our Shamrock consistency.

e.g. shamrock.hibernate.show_sql (from ORM's choice) or shamrock.hibernate.log-sql (Shamrock consistency.

[emmanuelbernard]

Brochette case please vote with thumbs up emoji on the comment

[emmanuelbernard]

OF COURSE THERE IS ALWAYS SHOUTINGCONVENSION

[gsmet]

Or come with our own disregarding the library to favor our Shamrock consistency.

I think the configuration properties handled by Shamrock itself should be consistent and we can have them different from the ones from the framework as soon as we document things.

In ORM, some of the property names are not ideal (either due to history or JPA) and having simpler, more user-oriented name would be nice.

[dmlloyd]

The configuration WIP branch currently supports "brochette" and camelCase. The preferred variant is just a question of changing the default.

[dmlloyd]

More complex cases are supported as well; consider this contrived example:

shamrock.thread-pool.special-pool.max-size=123

This would correspond to a Map<String, ThreadPoolConfigGroup> internally which has a maxSize field and would be assigned to a field named threadPool. It is assumed that . is used to divide segments.

[Sanne]

so clearly "pixel.case" is to be thrown out, as it would introduce ambiguity with the hierarchy separator.

[dmlloyd]

this-issue-is-done