Repository navigation
fix(java): prefer base vendor for latest command and ensure proper sorting - #11109
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughJava remote-version sorting now parses metadata versions and prefers base vendor variants. The CLI end-to-end test verifies that ChangesJava version ordering
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR adjusts Java version ordering in the core Java plugin so mise latest selects the expected release when multiple vendor “variants” exist (e.g., liberica vs liberica-nik), and improves sorting when the displayed version string includes extra vendor/features segments.
Changes:
- Sort Java entries using
JavaMetadata.version(the numeric version) rather than the full rendered string key, fixing ordering for vendor strings with extra-feature-segments. - Add a secondary sort key that prefers “base” vendors (fewer
-in the vendor name) solatestresolves to the canonical vendor when multiple match. - Extend the
mise latestE2E test to assert base-vendor preference forjava@liberica.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/plugins/core/java.rs | Updates remote-version sorting to use numeric metadata version and prefer base vendors for latest resolution. |
| e2e/cli/test_latest | Adds an assertion ensuring mise latest java@liberica resolves to the base vendor (not a variant like liberica-nik). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Greptile SummaryThis PR fixes two related bugs in the Java plugin's version sorting for the
Confidence Score: 5/5Safe to merge — changes are narrowly scoped to the sort key in one method and add a new e2e test for the fixed behaviour. Both changes are straightforward and well-motivated: using the raw numeric version for Versioning parsing is clearly more correct than feeding it a vendor-prefixed string, and the vendor_dashes heuristic is simple, non-destructive, and backed by a new end-to-end test. No files require special attention. Important Files Changed
Reviews (2): Last reviewed commit: "Merge branch 'main' into issues/11096" | Re-trigger Greptile |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/plugins/core/java.rs`:
- Around line 418-423: Update build_num extraction in the Versioning flow to use
only the '+' suffix; remove the fallback that splits on '.'. Preserve the
default build number behavior when no '+' build metadata exists, while allowing
Versioning to handle dot-separated version segments.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 09633500-2db5-4618-aba6-8cc14415932d
📒 Files selected for processing (2)
e2e/cli/test_latestsrc/plugins/core/java.rs
| let version = Versioning::new(&m.version); | ||
| // Extract build suffix after a '+', '.' if present. If not present, treat as 0. | ||
| let build_num = v | ||
| let build_num = m | ||
| .version | ||
| .rsplit_once('+') | ||
| .or_else(|| v.rsplit_once('.')) | ||
| .or_else(|| m.version.rsplit_once('.')) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Remove the fallback that splits on . for build_num extraction.
The .or_else(|| m.version.rsplit_once('.')) fallback can mistakenly extract the patch version as the build number for releases lacking build metadata (e.g., for 17.0.2, it extracts 2).
If Versioning ignores build metadata in precedence (per SemVer), this creates a sorting inversion where an older base release like 17.0.2 (incorrectly assigned build_num = 2) sorts higher than its own subsequent build like 17.0.2+1 (correctly assigned build_num = 1). Since Versioning natively handles dot-separated version segments (like 17.0.2.8), build_num is strictly only needed to break ties for + suffixes.
💡 Proposed fix
- // Extract build suffix after a '+', '.' if present. If not present, treat as 0.
+ // Extract build suffix after a '+' if present. If not present, treat as 0.
let build_num = m
.version
.rsplit_once('+')
- .or_else(|| m.version.rsplit_once('.'))
.and_then(|(_, tail)| {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let version = Versioning::new(&m.version); | |
| // Extract build suffix after a '+', '.' if present. If not present, treat as 0. | |
| let build_num = v | |
| let build_num = m | |
| .version | |
| .rsplit_once('+') | |
| .or_else(|| v.rsplit_once('.')) | |
| .or_else(|| m.version.rsplit_once('.')) | |
| let version = Versioning::new(&m.version); | |
| // Extract build suffix after a '+' if present. If not present, treat as 0. | |
| let build_num = m | |
| .version | |
| .rsplit_once('+') |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/plugins/core/java.rs` around lines 418 - 423, Update build_num extraction
in the Versioning flow to use only the '+' suffix; remove the fallback that
splits on '.'. Preserve the default build number behavior when no '+' build
metadata exists, while allowing Versioning to handle dot-separated version
segments.
Fixes sorting for multi-feature vendor prefixes and adds preference for base vendor in context of
latestcommand as mentioned in #11096.Summary by CodeRabbit
latest java@libericaresolves to the base Liberica version format.