Repository navigation
fix: 🐛 resolve transitive dependency types inside Kotlin-mirrored JARs - #183
Conversation
Classes in a JBang JAR mirrored as a module library (Kotlin support) were resolved against the module classpath only, so types declared in sibling Java JARs showed up as "Unknown class" or "Required type: X / Provided: X". The resolve scope enlarger now gives classes inside a JBang JAR the owning script's full classpath. Fixes jbangdev#180
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
|
👋 @maxandersen don't hesitate to ask me if you need more input 🤗 |
There was a problem hiding this comment.
🟡 Changes recommended
Multi-root classpath isolation, a central invariant of the fix, lacks regression coverage.
1 open finding
What changed in this PR
Fixes transitive type resolution for classes inside Kotlin-mirrored JBang dependencies.
Changes:
- Enlarges JAR resolve scopes using the owning script’s classpath.
- Adds cross-JAR highlighting regression tests.
- Updates architecture documentation and changelog.
| File | Description |
|---|---|
CHANGELOG.md |
Documents the fix. |
docs/modules/ROOT/pages/architecture.adoc |
Explains JAR resolve-scope behavior. |
JBangResolveScopeEnlarger.kt |
Applies owning-root classpaths to JAR entries. |
JBangProjectService.kt |
Determines the appropriate owning root. |
JBangLibraryProviderTest.kt |
Tests cross-JAR type compatibility. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Covers the Copilot review finding on jbangdev#183: when a dependency JAR is shared by two root scripts with different classpaths, classes inside that JAR must resolve against the active root's classpath only and must not leak the other root's sibling JARs. Exercises the active-root selection branch in getLibraryRootsForLibraryRoot.
|
@philippart-s thanks for the fix - i added an additional test - let me know if you see issues with it. if not and the tests still passes i'll merge it. |
|
hi @maxandersen all tests pass 👌 |

Fixes #180
Problem
When a declared dependency is a Kotlin library (e.g.
spring-ai-client-chat,openai-java-core), types that its signatures reference from a sibling Java JARare reported as errors, although the script compiles with
javacand runs with JBang:Required type: ChatMemory / Provided: ChatMemoryUnknown class: 'com.fasterxml.jackson.databind.json.JsonMapper'Cause
JBangKotlinLibraryMirrormirrors only the Kotlin JARs of the active root into amodule library so that K2 can build light classes. A class inside a mirrored JAR then
gets the module's resolve scope (
LibraryRuntimeClasspathScope), which does notinclude the root's plain Java JARs. Types from those JARs stay unresolved in the
mirrored class's signatures.
Classes in non-mirrored JARs are not affected: their resolve scope covers all
libraries.
Fix
JBangResolveScopeEnlargernow handles files inside a JBang JAR: their resolve scopeis enlarged with the full classpath of the root script that owns the JAR (the active
root if it owns it, otherwise the single owning root). Classpaths of different roots
are never merged, to avoid mixing dependency versions.
Tests
JBangLibraryProviderTestcompiles two JARs (clientreferencingapi.Memoryas aparameter and a return type) and highlights a script using them:
testTypeFromTransitiveJarIsCompatibleAcrossJarBoundary: plain Java client (control).testTypeFromTransitiveJarIsCompatibleWhenDependencyIsKotlinLibrary: Kotlin client,mirrored to the module. Fails without the fix with the errors reported in False "Required type: X / Provided: X" when the argument type comes from another jar #180
(
Incompatible types. Found: 'api.Memory', required: 'api.Memory',Unknown class: 'api.Memory').Full suite: 203 tests, 0 failures. Also checked manually with
runIdeon thereproducers from #180 (Spring AI and OpenAI SDK).
CHANGELOG.md([Unreleased]) andarchitecture.adocare updated.