Skip to content

Resolve all scaladoc link warnings - #55

Merged
russwyte merged 1 commit into
mainfrom
fix/scaladoc-link-resolution
Aug 4, 2026
Merged

Resolve all scaladoc link warnings#55
russwyte merged 1 commit into
mainfrom
fix/scaladoc-link-resolution

Conversation

@russwyte

@russwyte russwyte commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

The doc task emitted 20 Couldn't resolve a member for the given link query warnings. They show up in publish runs because those build javadoc jars; compile is clean, which is why they went unnoticed.

Every one of the 20 targets existed. None was a typo. All 20 were scaladoc resolution scope problems.

Two causes

Bare member links (14). Scala 3 scaladoc will not resolve [[Raw]] from enum Cron's own doc comment, but resolves [[Cron.Raw]] fine. Same shape for Defaults, LocalDir, Fixed, GitTags, Script, AffectedOnly, Always.

Cross-module links (6 fixed by qualification). The short form does not resolve across modules but the fully-qualified form does: [[Workflow]] becomes [[zipx.workflow.Workflow]] from core, and [[Capability.deploy]] becomes [[zipx.core.Capability.deploy]] from the plugin.

The unreachable remainder (6, converted to backticks)

These target things that can never be on the module's doc classpath:

  • PlannerSpec, a test source.
  • Yaml, from external zio-blocks.
  • zipx.specular.ZipxDocs / .pages and zipx.sbt, which sit downstream of core given the workflow <- core <- {central, sbt-plugin} direction, so a link from core can never reach them.

Backticks match the convention already in that prose: RemoteCacheProof carried a broken [[PlannerSpec]] directly beside a working `RemoteCacheItSpec`.

Verification

  • sbt "cleanFull; doc" now reports zero link warnings. The only remaining output is Option -classpath was updated (x4, one per module running doc), an sbt notice that is not actionable.
  • scalafmtCheckAll clean. The longer qualified names pushed several comment lines past maxColumn = 120, so scalafmtAll reflowed 7 files; doc was re-run after the reflow to confirm the wrapping did not break a link.
  • 304 tests pass across core / workflow / central / docs (testFull, not testQuick).
  • zipxWorkflowCheck clean.

Comments only; no code path is touched.

The doc task emitted 20 "Couldn't resolve a member for the given link
query" warnings, visible in publish runs since those build javadoc jars.
Every target existed; each was a resolution-scope problem.

Two causes, two fixes:

Bare member links in a doc comment attached to the enclosing enum or
class do not resolve ([[Raw]] from enum Cron's own comment). Qualifying
them fixes it, as does qualifying cross-module links fully
([[Capability.deploy]] in the plugin becomes
[[zipx.core.Capability.deploy]]).

Six targets are genuinely outside any doc classpath: test sources
(PlannerSpec), an external library (Yaml, from zio-blocks), and
zipx.specular.ZipxDocs / zipx.sbt, which sit downstream of core given
workflow <- core <- {central, sbt-plugin}. Those become backticks,
matching the convention already used beside them (RemoteCacheProof
referenced a broken [[PlannerSpec]] next to a working `RemoteCacheItSpec`).

Comments only. `doc` now warns only about "Option -classpath was
updated", an sbt notice that is not actionable.
@russwyte
russwyte merged commit 9a1f45a into main Aug 4, 2026
7 checks passed
@russwyte
russwyte deleted the fix/scaladoc-link-resolution branch August 4, 2026 00:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant