Hi @U04VDKC4G! Here's the https://github.com/cljdoc/cljdoc/blob/master/doc/userguide/for-library-authors.adoc#getting-dependencies-right. If you are still stuck or have questions I'm around to try and help.

I'm banging my head around it; deps.edn does seem to have an easy way to inject the optional dependencies into the pom.xml.

Did you mean to type "does not seem"? If so, ya, it is awkward with deps.edn to a add provided deps. Some approaches can be found in yesterday's thread.

Yeah I have raised as an issue as have the same problem.

I was unclear whether the best fix was to be able to choose an alias (or aliases) for cljdoc, or to inject ‘provided’ deps into my jar during build.

@U04VDKC4G, I've not ever tried the cljdoc-check-action. I wonder if there is something amiss with it. I do see https://github.com/cljdoc/cljdoc-check-action/issues/3 asking about one aspect of it. I'll take a peek sometime soon and get back to you.

Hmmm... I'm looking at how https://github.com/cljdoc/cljdoc-analyzer#use-as-a-clojure-cli-tool. It assumes: >

# provided ./pom.xml and ./target/*.jar exist

Raised an issue: https://github.com/cljdoc/cljdoc-check-action/issues/4

@U04VDKC4G, if @U0522TWDA is too busy to take a peek at this one, I will do so probably tomorrow.

I think lein, by default, generates a pom.xml in the current directory.

Maybe it came from that use case... but the pre-amble sez "Analyze a deps-based library in the current directory", which I think means a deps.edn based project. But whatever. Unless someone thinks of why we would-not/should-not use the pom in the jar by default, we'll make it do so soon.

@U04VDKC4G, In the meantime, a CI workaround for you. After you generate your jar you could:

cp target/classes/META-INF/maven/io.aviso/pretty/pom.xml .

I'm holding off on integrating pretty w/ cljdoc. It's funny, pretty is an example in the docs for how to work around a lib that doesn't conform!

https://github.com/cljdoc/cljdoc-check-action

I noticed that too!

And it ain't pretty! Or is it? It is pretty but it ain't pretty. We'll fix things up. Thanks for taking the check action for a spin, I'm not sure how widely it has been adopted and your feedback here will help us to slap it into shape.

I'm excited to get some of my libs into cljdoc; it simplifies my life for sure, and it's a very valuable service. I did try to run some of this locally, but I'm on an M1 Mac so the Docker images were problematic and appears to run very, very slow. Or I just didn't know what was going on.

A good solution for Pretty might be to break it up into three parts: core pretty, a lein plugin (or just drop that entirely), and an extension lib that has the extra setup for component and tools.logging.

That would be a 2.0 release. Which is not out of the question.

But that would bypass the entire optional dependencies issue.

Might be a chance to move it under clj-commons.

And strip out some of it.

Yeah, the current local preview story for cljdoc mimics production but is certainly not local-friendly.

Hello! Sorry I did not see the issues, I will try to set up notification in GH for that. To your question, I do not remember anything 😅 (one of the reasons I blog a lot). I will have a look at the code. But it should work for a deps.edn - based library because that is what it was built for and tested with.

@UE21H2HHD I believe it boils down to the fact that I used existing capabilities in the analyzer, and there was (is?) no support for reading the pom file from the jar. This https://github.com/cljdoc/cljdoc-analyzer/blob/f10878e83ca85f758faf21ee5555524394edbac7/src/cljdoc_analyzer/runner.clj#L174 is where cljdoc tries to read the POM. If we want the analyzer to be able to use the pom in the jar, then we could perhaps change the line to st. like

- pom-str (slurp pompath) 
+ pom-str (or (slurp pompath) (slurp (str  jar-contents-dir "/" pompath))) ; does this break on windows?

Oh, I see it is a little more complicated, since the pom in the jar is at META-INF/maven/<group>/<library>/pom.xml so we’d need to be smarter at finding it…

Yeah, I'm sure glad I take notes @U0522TWDA, because I remember very little too!

I can take a peek at cljdoc-analyzer and see what might be done there to support using the pom from within the jar there. Also, I vaguely remember some use case where the pom was not in the jar. Was it https://github.com/juxt/pack.alpha that supported this style? Ya https://github.com/cljdoc/cljdoc-analyzer/issues/29.