cljdoc

Mark Wardle 2023-03-29T11:50:47.156119Z

Hi all. I have removed a dependency from deps.edn for one of my libraries as it is optional. It would therefore be :scope provided using older tooling... (although I never used lein myself). However, this now means clojars can't build documentation, as one of my namespaces requires that third-party dependency. I've read https://github.com/cljdoc/cljdoc/blob/master/doc/fixing-builds.md but I'm unsure how to fix. Is there a way of providing an alias, or set of aliases to use in the cljdoc build? I don't think deps.edn supports listing optional dependencies except through aliases. I'd be grateful for for any pointers. Thank you!

Mark Wardle 2023-03-29T12:14:13.891499Z

I tried using a source pom.xml with the required dependency explicitly listed as 'provided', but it appears the whole <dependencies> section is overwritten by tools.build so don't think that will work.

Sam Ritchie 2023-03-29T14:35:11.901929Z

Lines 7-38 are my solution here…

Mark Wardle 2023-03-29T14:50:14.476379Z

That looks clever. Thank you! It feels as if the standard tools.build write-pom could support adding in other deps or merging any deps from a source template POM with those from deps.edn.

Sam Ritchie 2023-03-29T14:51:16.925819Z

That would be better for sure

πŸ‘ 1
lread 2023-03-29T16:54:35.430579Z

Hmm... yes this flow is a tad awkward. I really should get around to finishing up implementing static API analysis for cljdoc. For libs that don't dynamically generate their API at load time (potemkin import-vars type stuff), static analysis would do the trick without any need for specifying any provided deps.

Mark Wardle 2023-03-29T16:57:41.516419Z

Thanks @lee - although my reflections on this are that to play nicely with the Java ecosystem my pom.xml should include optional dependencies with scope 'provided'. So, I have asked a question on http://ask.clojure.org. https://ask.clojure.org/index.php/12817/tools-support-providing-additional-dependencies-provided

lread 2023-03-29T17:02:07.552609Z

Ya, fair point, thanks @mark354!

πŸ‘ 1
seancorfield 2026-05-21T20:46:59.042609Z

I stumbled across this problem just now, with my rephrase library, and noticed that write-pom in tools.build supports :optional true in a dependency (in deps.edn) and adds <optional>true</optional> to the pom.xml file. This seems similar to <scope>provided</scope> -- and deps.edn-based projects seem to correctly ignore such transitive deps when depending on Maven/Clojars artifacts with optional deps (good). So I wondered whether cljdoc would be happy with an optional dep, rather than a provided-scope dep? (I'm currently using a build.clj hack to modify the generated pom.xml to replace <optional>true</optional> with <scope>provided</scope> for now, even tho' Maven says they have different semantics, but haven't tested cljdoc with an optional dep) If this works, it would seem to be a supported way to handle this problem for cljdoc going forward (use an alias in deps.edn to add the necessary deps with :optional true in their coords, create a basis with :aliases for use in write-pom).

lread 2026-05-21T20:57:43.476849Z

Seems like a good idea to me, @seancorfield

seancorfield 2026-05-21T20:58:49.089349Z

If it works for cljdoc. I haven't tested it.

lread 2026-05-21T21:18:00.623459Z

Ya, I can take a peek sometime soon

seancorfield 2026-05-21T21:29:18.128429Z

Confirmed that :optional true works with http://cljdoc.org!

πŸŽ‰ 3
lread 2026-06-01T15:34:54.691229Z

Thank you @seancorfield, I'll update the cljdoc docs and cljdoc-analyzer tests.

lread 2026-05-31T18:45:45.754029Z

Anybody using :optional true? I could reference your lib as an example from docs... and add it to the cljdoc-analyzer real-world lib tests.

seancorfield 2026-05-31T21:08:05.575929Z

I use it in rephrase -- https://github.com/seancorfield/rephrase/blob/main/deps.edn#L4-L6

seancorfield 2026-05-31T21:10:14.092809Z

I write the POM and build the JAR with the :optional alias, so it ends up in pom.xml which satisfies http://cljdoc.org but projects that depend on it (on http://clojars.org) don't bring nrepl/nrepl in as a transitive dependency.

πŸ‘ 1