[Jeppe Fredsgaard Blaabjerg (jfblaa)]

LLM Description written by Claude Code:claude-opus-5-5

sbt dependencies whose jars could not be fetched looked resolved:

• Coursier silently skips a default jar it cannot find unless the POM declares jar packaging; the plugin now reads the cached POM's packaging to tell a missing jar from a POM-only, war or aar module.
• Ivy's download failures, which sbt 0.13's update report omits, are read from Ivy's own resolution report.
• Both are reported under the full coordinate and marked unfetched.
• Covers coursier (sbt 1.3+), Ivy (sbt 0.13) and sbt 1.x with useCoursier := false.

Testing: failure compat suite extended with an artifact-failure build; new sbt 1.9.9 Ivy row. Passes on sbt 0.13.18, 1.4.9, 1.6.2, 1.9.9 and 1.9.9 with Ivy.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes sbt manifest resolution and failure reporting for reachability SBOMs; incorrect classification could still mislabel dependencies, but scope is limited to the sbt facts plugin and is heavily covered by compat tests.

Overview
sbt Socket facts now treat missing jars as real resolution problems instead of silently looking like POM-only modules.

The socket-facts.plugin.scala plugin distinguishes Coursier’s silently skipped default jars from intentional pom, war, and aar modules by reading cached POM packaging, surfaces Ivy download failures from Ivy XML reports when sbt omits them, and emits failure / unfetched records (with full coordinates and config scope). Lenient update handling is shared across projects so upstream artifact-only failures do not wrongly mark dependents unscannable.

Compat tests add stub fixtures (nojar, pomonly, pkwar, classifier jars), an artifact-failure multi-module build, --with-files assertions, and an sbt 1.9.9 / Ivy matrix row.

^{Reviewed by Cursor Bugbot for commit 837f6ec. Configure here.}

[Martin Torp (mtorp)]

[agent] Approving, with two inline notes.

One behaviour to be aware of: a POM with no <packaging> and no jar resolves cleanly in sbt, but with --with-files the plugin now reports it as a blocking failure. A real case is log4j:log4j:1.2.15, which pulls in javax.jms:jms:1.1 and com.sun.jmx:jmxri:1.2.1. Both POMs have no packaging and both jars 404 on Central. Marking them unfetched for reachability makes sense. Whether they should block is the policy question I raised on #1647. I reproduced the blocking with a local fixture on sbt 1.9.9.