if you want to deal with the list programmatically, it's a bit much overhead for interactive applications.
sdk update could easily store lists of available versions, e.g. as CSV in
.sdkman/var/versions/$candidate
(which could even deprecate .sdkman/var/candidates).
Side note: storing candidates and versions one per line might be more helpful for consuming shell scripts.
Concrete use cases:
Auto-completion: sdk install java 8.<tab> should complete in meaningful ways.
Faster sdk ls $candidate (which might warn if the stored data is old).
Please tick one:
Please explain the Issue / Feature Request here:
Store available candidate versions, just like the list of candidates.
Rationale: While versions can be retrieved via
sdk ls $candidate
, orif you want to deal with the list programmatically, it's a bit much overhead for interactive applications.
sdk update
could easily store lists of available versions, e.g. as CSV in(which could even deprecate
.sdkman/var/candidates
). Side note: storing candidates and versions one per line might be more helpful for consuming shell scripts.Concrete use cases:
sdk install java 8.<tab>
should complete in meaningful ways.sdk ls $candidate
(which might warn if the stored data is old).