Conditionally enable and disable CLI options #13113
Description
Description
Options might not make sense if some other option is used when running the CLI. This is especially true when using build options that usually enable or disable a specific provider and its configuration.
It might make sense to conditionally enable/disable options depending on the build options set so that the CLI reflects the configuration state of the distribution. This capability can potentially consider the values set to options too.
A use case for this capability is related to the new store integration and the middle/long-term support for the legacy store. The legacy store relies on a cache configuration whereas the new store does not provide any cache settings but its own way to structure different stores in a tree store.
Another example is to remove the db option completely when storage=jpa|chm.
Right now is a bit confusing to see:
Cluster:
--cache <type> Defines the cache mechanism for high-availability. By default, a 'ispn' cache
is used to create a cluster between multiple server nodes. A 'local' cache
disables clustering and is intended for development and testing purposes.
Default: ispn.
--cache-config-file <file>
Defines the file from which cache configuration should be loaded from. The
configuration file is relative to the 'conf/' directory.
--cache-stack <stack>
Define the default stack to use for cluster communication and node discovery.
This option only takes effect if 'cache' is set to 'ispn'. Default: udp.
Storage (Experimental):
--storage <type> Experimental: Sets a storage mechanism. Possible values are: jpa, chm.
Database:
--db <vendor> The database vendor. Possible values are: dev-file, dev-mem, mariadb, mssql,
mysql, oracle, postgres. Default: dev-file.
And have the db or cache options available even though the distribution is configured as follows:
kc.sh build --storage chm
I would expect to see this instead:
Storage (Experimental):
--storage <type> Experimental: Sets a storage mechanism. Possible values are: jpa, chm.
And potentially unlock more options after choosing a specific storage.
At the same time, I'm not sure about the UX when you have a vanilla distribution. If we should show all options and filter them afterwards or if we should impose some flow through the CLI so that options are unlocked only after some initial configuration is done. For instance, suppose you just extracted a distribution and you run:
kc.sh build -h
It would show the following help because legacy storage is enabled by default:
Cluster:
--cache <type> Defines the cache mechanism for high-availability. By default, a 'ispn' cache
is used to create a cluster between multiple server nodes. A 'local' cache
disables clustering and is intended for development and testing purposes.
Default: ispn.
--cache-config-file <file>
Defines the file from which cache configuration should be loaded from. The
configuration file is relative to the 'conf/' directory.
--cache-stack <stack>
Define the default stack to use for cluster communication and node discovery.
This option only takes effect if 'cache' is set to 'ispn'. Default: udp.
Storage (Experimental):
--storage <type> Experimental: Sets a storage mechanism. Possible values are: jpa, chm, legacy. Default: legacy.
Database:
--db <vendor> The database vendor. Possible values are: dev-file, dev-mem, mariadb, mssql,
mysql, oracle, postgres. Default: dev-file.
Note the change to storage description:
--storage Experimental: Sets a storage mechanism. Possible values are: jpa, chm, legacy. Default: legacy.
Now, after setting storage=chm using the build command, the result would be just:
Storage (Experimental):
--storage <type> Experimental: Sets a storage mechanism. Possible values are: jpa, chm, legacy. Default: legacy.
I don't know if Picocli supports a construct like that:
kc.sh build --storage chm --help
Where help will show the message with only the options available for the storage=chm. The same goes for start --storage chm --help.
Also, when running :
kc.sh start --storage chm --cache local
You should get an error saying the cache is unknown because of the storage option being set to chm.
Discussion
No response
Motivation
Improve UX by hiding options that should not be set when other options are set.
Details
Not sure how much this is feasible (UX and code-wise) or if just complicates more the UX. I have a feeling that it provides a more concise usage and understanding of the available options.
### Follow-up Tasks
- [ ] https://github.com/keycloak/keycloak/issues/27025
- [ ] https://github.com/keycloak/keycloak/issues/27026