feat: add info source-jar and source-path commands

[arnabnandy7]

Description

Implemented jbang info source-jar and jbang info source-path to resolve and print source JARs for archives, dependencies, and scripts, complementing the existing jbang info jar and jbang info classpath commands:

• jbang info source-jar <scriptOrJar>: Resolves and prints the path to the source JAR for a specified JAR file, archive, or Maven GAV coordinate (via sibling check, embedded pom metadata, or Maven repository resolution). Fails with a non-zero exit code when no source JAR is available.
• jbang info source-path <scriptOrJar>: Resolves and prints the operating-system-specific separated path (: on Unix, ; on Windows) of source JARs for project dependencies, with --deps-only option support to omit the application source archive.
• jbang info tools: Added --download-sources flag and populated applicationSourceJar and resolvedSourceDependencies fields in ScriptInfo (also triggered automatically when querying source fields via --select).
• Dependency Resolution & Cache: Updated ArtifactResolver, DependencyCache, DependencyUtil, and ModularClassPath to resolve, track, and cache source JAR paths alongside binary artifacts.
• Documentation & Tests: Added documentation pages jbang-info-source-jar.adoc and jbang-info-source-path.adoc, updated troubleshooting.adoc and CLI navigation docs, and added unit tests in TestInfo.

Fixes #2663

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• ai-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 2edd9fe0-e563-4334-be2b-b60dc7cda7e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[maxandersen]

this works good for GAV's but it fails on aliases/scripts.

jbang info source-jar env@jbangdev ...could/should we make that work?

[arnabnandy7]

this works good for GAV's but it fails on aliases/scripts.

jbang info source-jar env@jbangdev ...could/should we make that work?

Currently source-jar only resolves for executable archives (JARs) or GAV coordinates (!prj.isExecutableArchive() exits early), which is why scripts and script aliases fail with No source JAR found.

We could definitely support this! Similar to how info jar outputs the cached application JAR (~/.jbang/cache/jars/<script>.<id>/<script>.jar), info source-jar could package the script and any files declared via //SOURCES or resources into a cached <script>-sources.jar in that same directory (creating it on demand if not already present).

@maxandersen would you like me to include that script source-jar packaging in this PR, or should we keep this PR focused on GAVs / JARs and follow up with script source-jar generation in a separate PR?

[maxandersen]

About source jar for scripts then let's do that separately - I might be a bit more gnarly to do :)

[arnabnandy7]

About source jar for scripts then let's do that separately - I might be a bit more gnarly to do :)

right, let's keep this PR focused on JARs and GAVs and tackle script source-JAR generation in a follow-up.

[maxandersen]

lgtm

[maxandersen]

finding a few nits/bugs:

1. returning wrong source jar when sources dont exist:

jbang info source-jar io.netty:netty-tcnative-boringssl-static:2.0.61.Final /Users/max/.m2/repository/io/netty/netty-tcnative-classes/2.0.61.Final/netty-tcnative-classes-2.0.61.Final-sources.jar

it should be empty. instead it seems to be first transitive source jar?

2. mixed casing in cache file - could just use "sources-file" and "sources-checked" or maybe just presence of "sources-file": null is enough?

3. above made me also realising there aren't actually any tests for this feature (incl. no source available) so lets fix that first.

[arnabnandy7]

finding a few nits/bugs:

1. returning wrong source jar when sources dont exist:

jbang info source-jar io.netty:netty-tcnative-boringssl-static:2.0.61.Final /Users/max/.m2/repository/io/netty/netty-tcnative-classes/2.0.61.Final/netty-tcnative-classes-2.0.61.Final-sources.jar

@maxandersen that happened because resolveDependencies returns the entire resolved tree, and when the requested artifact didn't have sources, the stream search was falling through and picking up the first transitive dependency that did (netty-tcnative-classes).

I updated DependencyUtil.resolveSource to filter the resolved artifacts specifically by the target coordinate's groupId and artifactId so transitive dependencies are ignored. Also updated Info.resolveApplicationSourceJar to return immediately once the application JAR artifact is checked.

Running jbang info source-jar io.netty:netty-tcnative-boringssl-static:2.0.61.Final now properly fails with an error indicating no sources were found.

it should be empty. instead it seems to be first transitive source jar?

2. mixed casing in cache file - could just use "sources-file" and "sources-checked" or maybe just presence of "sources-file": null is enough?

Standardized the keys to "sources-file" and "sources-checked".

I looked into doing "sources-file": null, but Gson omits null properties by default during serialization unless .serializeNulls() is turned on globally on the builder (which would start serializing nulls everywhere in the cache file). Having an explicit "sources-checked": true keeps the JSON clean and unambiguous.

The deserializer also still handles the older camelCase keys (sourceFile, sourcesChecked) so existing cache files continue to work without issue.

3. above made me also realising there aren't actually any tests for this feature (incl. no source available) so lets fix that first.

Added tests for the both:

• In TestInfo: added testInfoSourceJarForGavWithoutSources and testInfoToolsForGavWithoutSources using io.netty:netty-tcnative-boringssl-static:2.0.61.Final. They verify that info source-jar exits cleanly with an error when sources don't exist and that info tools --download-sources keeps applicationSourceJar as null without leaking transitive sources.
• In TestArtifactInfo: added testDependencyCacheWithSources to test the cache serialization format (sources-file, sources-checked) and confirm that round-trip parsing restores the source file paths and checked status accurately.

[maxandersen]

Realizing that resolveSource() goes through resolveDependencies() → ArtifactResolver.resolve(), which builds an Aether DependencyRequest (fully transitive), and since downloadSources=true is passed, this runs over the whole tree:

return artifacts.stream().map(ar -> {
    if (downloadSources) sourcePath = downloadSources(ar.getArtifact())...

So jbang info source-jar io.netty:netty-tcnative-boringssl-static:2.0.61.Final currently:

1. resolves netty-tcnative's full transitive tree,
2. downloads source jars for every artifact in it,
3. then .filter(group/artifact) throws all but one away.

Your previous method avoided that so probably better to return that as otherwise source-jar gets to be very slow even when it do not have to be.

[arnabnandy7]

Your previous method avoided that so probably better to return that as otherwise source-jar gets to be very slow even when it do not have to be.

@maxandersen Reverted the changes.