Clojurians Log v2

https://app.circleci.com/pipelines/github/cljdoc/builder/29876/workflows/f01d7949-8147-4883-8de2-25a5b723d572/jobs/46251

unfortunately a search for cannot be cast to class clojure.pprint.PrettyFlush here or on GH does not help

@huxley, happy to take a peek sometime today. But first... I see many clojure .class files in your jar. This is something you typically want to avoid for a library.

You probably want to use b/jar instead of b/uber https://github.com/ribelo/doxa/blob/9a9571f3e7c49bac186512028e99ed4f15eefcce/build/build.clj#L65-L67?

when using jar, I have a problem with dependencies

I copied the config from malli

An uberjar is typically for apps, not libs.

my problem was the dependencies served from github

after uploading to clojars and making jar and not uberjar, it seems to work now

thanks for your help again

Woot!

Congrats, and you are most welcome.

Oh @huxley, one more thing: your cljdoc badge image seems a bit off: You have: https://cljdoc.org/badge/ribelo/doxa.svg But I think you maybe want: https://cljdoc.org/badge/com.github.ribelo/doxa

definitely 😉

Hi @djblue! Thanks for dropping by!

Our current recommendation is to include optional deps as provided in your pom.xml .

The only option today for API analysis is dynamic analysis, your namespaces are loaded to discover your API. I am exploring adding support for static analysis via clj-kondo’s analysis data. Static analysis would not always cover the case where an API is generated at load-time, but not many libs do this, so it might be a good fallback/option if dynamic analysis fails.

It would be awesome if I could opt-in to the static analysis path for some apis/namespaces 💯

And am also looking at custom analysis. You provide the resulting API analysis edn that cljdoc normally generates. But… I don’t think this is what your use case specifically needs.

> It would be awesome if I could opt-in to the static analysis path for some apis/namespaces Oh… hadn’t thought of doing only for some namespaces… Hmm… I’d probably start with all static or all dynamic for an analysis run.

Recently I added some code for planck and had some issues, luckily planck does publish a jar to clojars so I was able to solve the issue.

Another option could be to exclude certain namespaces from being analyzed 🤔 Not sure what is easier

Just remembered that cljdoc does add at least one jar to the classpath that would fall into the provided category: javax.servlet/javax.servlet-api.

Am thinking maybe lein might be another one to add for lein plugins.

> Another option could be to exclude certain namespaces from being analyzed 🤔 Not sure what is easier If you have control over the source, you can add :no-doc to a namespace. A recent change to analysis will not attempt to explicitly load these namespaces. But if they are loaded indirectly by other code in your lib, then… well… you’ll still have trouble.

Ohh, I think I might be using an older version of cljdoc locally for testing. I was hoping no-doc would do this 💯

It should! You can thank @vemv for the idea, and blame me if it doesn’t work. simple_smile

Okay, this is a great tip 🙏

Thanks again for all the hard work you do ❤️

Meh, it is typically lotsa fun! And always looking for feedback. It can get a little quiet in the ol’ cljdoc channel so feel free to drop by with ideas/problems/suggestions.