🐛 On windows with certain Quarkus applications Java is not found as a language#710
Conversation
📝 WalkthroughWalkthroughReplaces direct language analysis with component-based detection, flattens component Languages into a languages collection, tightens provider selection via a whitelist and weight gates, adjusts list/filter thresholds and error text, and adds tests for non-default language provider mapping. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI as CLI
participant Recognizer as Recognizer
participant ProviderMgr as ProviderManager
participant Analyzer as Analyzer
CLI->>Recognizer: DetectComponents(input)
Recognizer-->>CLI: components (each has Languages)
CLI->>CLI: flatten component Languages -> languages list
CLI->>ProviderMgr: setProviders(maps.Values(languages))
ProviderMgr-->>CLI: foundProviders
CLI->>Analyzer: run analysis with foundProviders and languages
Analyzer-->>CLI: analysis results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@cmd/analyze.go`:
- Around line 188-198: The flattened languages slice produced after
recognizer.DetectComponentsInRoot(analyzeCmd.input) can contain duplicates
across components, which later causes setProviders to create duplicate
foundProviders and invoke setProviderInitInfo/freeport.GetFreePort() multiple
times for the same provider; fix by deduplicating languages immediately after
the flattening loop (or alternatively deduplicate entries in foundProviders at
the end of setProviders) — use the existing variables/functions (the languages
slice, recognizer.DetectComponentsInRoot, setProviders, foundProviders,
setProviderInitInfo, freeport.GetFreePort) to implement a simple map[string]bool
keyed by language identifier to filter out duplicates before proceeding.
In `@cmd/command-context_test.go`:
- Around line 138-146: Update the test in cmd/command-context_test.go to fix
copy-paste mistakes: change the comment above the assertion to describe
Rust/non-default language behavior (not "JavaScript should map to nodejs
provider"), and correct the error message in the failing case to expect the
lowercase provider string used in the assertion (use "rust" consistently) when
checking the result from setProviders(); ensure the format string and passed
want value match (result[0] vs "rust").
🧹 Nitpick comments (2)
cmd/command-context.go (1)
52-58: Duplicated valid provider list.This
validProvsmap duplicates the list atcmd/analyze.go:566-572(validateProviders). Consider extracting a shared set/constant to keep them in sync.cmd/command-context_test.go (1)
112-147: Consider adding a test case for a non-default language below the 0.1 threshold.The test verifies that Rust (weight 0.3) passes, but it would be valuable to explicitly assert that PHP (weight 0.03) is not in the result, rather than only checking
len(result) == 1. This makes the test more resilient to future changes and documents the gating behavior for non-default languages more explicitly.🧪 Suggested assertion addition
if result[0] != "rust" { t.Errorf("setProviders() returned provider %s for non-default Rust, want %s", result[0], "rust") } + + for _, p := range result { + if p == "php" { + t.Error("setProviders() should not include php provider (weight 0.03 below 0.1 threshold)") + } + }
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (37.50%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #710 +/- ##
==========================================
+ Coverage 40.19% 40.23% +0.03%
==========================================
Files 38 38
Lines 5098 5113 +15
==========================================
+ Hits 2049 2057 +8
- Misses 2774 2781 +7
Partials 275 275 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
afba154 to
d9dd729
Compare
d9dd729 to
4bf73ff
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@cmd/analyze.go`:
- Around line 1555-1559: The listLanguages output uses a different weight cutoff
(l.Weight > .02) than setProviders (uses 0.001), causing inconsistency; update
listLanguages to use the same threshold as setProviders (0.001) or, better,
introduce a shared constant (e.g., languageWeightThreshold) used by both
listLanguages and setProviders so both provider selection and --list-languages
output align and avoid hiding default providers like Java/Python/Go.
| // This what alizer uses to determine languages today | ||
| // This will allow this to continue having the same behavior | ||
| if l.Weight > .02 { | ||
| fmt.Fprintln(os.Stdout, l.Name) | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
ast-grep --pattern $'func ($_ *analyzeCommand) setProviders($$$) {
$$$
}'Repository: konveyor/kantra
Length of output: 41
🏁 Script executed:
rg "setProviders" --type go -B 5 -A 15Repository: konveyor/kantra
Length of output: 16707
🏁 Script executed:
rg "func \(c \*AnalyzeCommandContext\) setProviders" -A 50 cmd/command-context.goRepository: konveyor/kantra
Length of output: 1738
🏁 Script executed:
rg "alizer" --type go -i -B 2 -A 2 | head -60Repository: konveyor/kantra
Length of output: 1501
🏁 Script executed:
rg "0\.02|\.02" --type go -B 3 -A 3Repository: konveyor/kantra
Length of output: 384
🌐 Web query:
alizer language detection weight threshold 0.02
💡 Result:
I couldn’t find any public documentation or source reference for an “alizer” language detection setting called “weight threshold” with value 0.02. The term “alizer” doesn’t appear to match a known/commonly documented language-detection library or API in the results I checked.
What I did find is that most language detectors expose confidence/probability thresholds (not usually called “weight thresholds”):
- AssemblyAI:
language_confidence_thresholdis a configurable cutoff in[0, 1]; the API errors if detected language confidence is below it. This is the closest mainstream concept to what you described (e.g.,0.02would be an extremely permissive threshold). [1] - Nakatani Shuyo / langdetect-derived implementations (e.g., azagniotov’s reimplementation) expose model parameters like
convergenceThreshold(default shown as0.99999)—again, not a “weight threshold 0.02”. [2]
If you tell me which project/package “alizer” refers to (link to repo/docs, or the config file / code snippet where you saw 0.02), I can pinpoint exactly what that threshold does and how it affects detection.
Sources: [1] [2]
🏁 Script executed:
cat go.mod | grep alizerRepository: konveyor/kantra
Length of output: 92
🏁 Script executed:
rg "0\.001" --type go -B 5 -A 2Repository: konveyor/kantra
Length of output: 41
🏁 Script executed:
rg "Weight > \." --type go -B 3 -A 1Repository: konveyor/kantra
Length of output: 885
Alignment issue: listLanguages threshold (0.02) differs from setProviders threshold (0.001 for default providers).
The --list-languages output filters by l.Weight > .02, but setProviders includes default providers (Java, Python, Go, etc.) with l.Weight > .001. This creates a mismatch where Java—or any default provider with weight between 0.001–0.02—would be selected for analysis but not displayed in --list-languages, contradicting the stated goal of preserving alizer's behavior.
Since this filtering controls both user-facing output and provider selection, aligning these thresholds will prevent confusing scenarios where users don't see a language option that analysis actually runs.
🤖 Prompt for AI Agents
In `@cmd/analyze.go` around lines 1555 - 1559, The listLanguages output uses a
different weight cutoff (l.Weight > .02) than setProviders (uses 0.001), causing
inconsistency; update listLanguages to use the same threshold as setProviders
(0.001) or, better, introduce a shared constant (e.g., languageWeightThreshold)
used by both listLanguages and setProviders so both provider selection and
--list-languages output align and avoid hiding default providers like
Java/Python/Go.
Signed-off-by: Shawn Hurley <shawn@hurley.page>
52c97be to
404f845
Compare
|
This is not fixing the issue in koncur. I am going to come back to this once I get the nightly working. |
dymurray
left a comment
dymurray
left a comment
There was a problem hiding this comment.
Looks good to me, CodeRabbit's comment about --list-languages not matching behavior is worth investigating but changes to bump weight for default providers makes a ton of sense
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. |
2 participants
This happens because the weight of the Java language falls below the threshold for the reconginzer. Using the components, we can assign our own weights; here, we will assign different weights depending on whether there is a default provider for that language.
Summary by CodeRabbit
Bug Fixes
Tests