Clarify SDKMAN errors when only specialised builds are listed

Aperta Adatta ai principianti
  • Qualcosa non va?
#108 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
67/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
r
Ambito
backend

Direzione di ricerca

Individua il resolver SDKMAN e i relativi test mirati; l’issue non indica i percorsi dei file. Leggi come il resolver distingue le corrispondenze di vendor e versione dalle build specializzate escluse, quindi esegui i test pertinenti con un catalogo simulato contenente solo build specializzate. Il lavoro è completato quando l’errore spiega l’esclusione e indica agli utenti la colonna identifier di java_list_available(backend = "sdkman"), mentre la politica di selezione e il comportamento di quiet restano invariati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Plain SDKMAN major and patch requests intentionally exclude unrequested JavaFX, CRaC, early-access and snapshot builds after #107. When the catalogue contains only such builds for a requested major, the resolver currently reports only No SDKMAN identifier for .... That does not explain why listed builds were excluded or how to opt in.

For example, with only 28.0.0.0+ea.20-open listed, a plain major request for OpenJDK 28 is rejected. This is the intended selection policy; the follow-up is to make the error actionable. The Opus review of #107 observed this catalogue case, but did not verify broker availability of that exact identifier. Availability remains a separate concern tracked in #106.

Suggested scope:

  • Distinguish a catalogue with no matching vendor/version from one whose matches were all excluded as specialised builds.
  • Explain that a plain request excludes experimental/specialised builds and direct users to the identifier column of java_list_available(backend = "sdkman") to choose an explicit full identifier.
  • Add a focused regression test for the error message using a mocked specialised-only catalogue.
  • Keep the existing selection policy and quiet behavior; do not introduce automatic experimental-build fallback or claim that every listed identifier is downloadable.

This is a nonblocking usability follow-up from the review of #107.

Lingua principale
R
Stelle
25
Fork
3
Merge medio
1g 19h
PR unite (30g)
4

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di e-kotov/rJavaEnv

Tutte le issue di e-kotov/rJavaEnv

Issue simili

Altre issue su R

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.