Clojurians Log v2

Currently figuring out SSL certs...

Ok, seems good now

Let us know if you stumble upon anything that seems amiss!

There's this PR, according to which the version tag has a slightly different format: https://github.com/cljdoc/cljdoc/pull/675/files

Awesome, thank you!

But there's also this code where it seems like the revision provided in pom.xml has precedence https://github.com/cljdoc/cljdoc/blob/85c9936adc2654f9439534e30e361cbb5adeddce/src/cljdoc/analysis/git.clj#L121-L125

Oh that's unfortunate.

Would be great if you could try and report back!

I'll give it a shot!

I might just not fully understand the code 🙂

yep, I even documented it: https://github.com/cljdoc/cljdoc/blob/master/doc/userguide/for-library-authors.adoc#overriding-cljdoc-config--articles

Unfortunately for my current main project #coffi I won't be able to use cljdoc anyway because for that I need JDK 22+ and potentially some other stuff like --enable-native-access=ALL-UNNAMED, but I'll give it a shot on farolero

Hmm... I wonder if there'd be any harm in bumping to latest JDK for analysis turning such switches....

Could you provide a Docker image that we can use for this? With that maybe we could just make an alternative builder env @lee?

Also v. open to just bumping and see how it goes!

Worth the experiment I think 🙂

Well, we discussed allowing the user to choose their jdk or docker image a while back but never implemented.

I was a bit concerned about maintaining such a thing moving forward through the years tbh.

But there's also static analysis via clj-kondo which I got pretty far on but have not finished yet. Do you imagine static analysis do the trick for you @suskeyhose?

(in other words, are you generating any part of your public API vars at a load time?)

I mean for coffi I think static analysis should do the trick. Besides if you can support clj-kondo hooks to produce vars then I already do everything with making those hooks understand my code and distribute it with my libraries too.

For coffi the only reason I need the bumped version is that I import classes that are only available in JDK 22 and later

Yeah, I think static analysis might do the trick for you. It won't be ready tomorrow, but I can restart work on that sometime soon. But in the shorter term... maybe bumping the dynamic analysis to JDK23 and turning on some JAVA_OPTS might work out too. I can run some tests.

👍

the repo I'm trying to get to work is https://github.com/IGJoshua/coffi if that helps

I think it would be fairly simple to swap the Circle CI project that we use for building, so if you can make a fork of https://github.com/cljdoc/builder we could hard code a path to use it for specific projects?

I guess? You mean as a hardcoded special-case kind of thing?

Not sure how "close" things are to static analysis working, that's obviously also a great alternative with better overall impact

I can try bumping cljdoc-analyzer CI to JDK23 with the java opts coffi needs and see if that breaks any of the libs we test against. Maybe it won't be a problem to do that for all dynamic analysis.

(here's the now dormant issue on allowing for different JDKs https://github.com/cljdoc/cljdoc/issues/275)

thanks so much! I love the amount of support y'all put into the community

Initial local tests look good; I only bumped to Temurin JDK23 and did not need to add any special Java opts to get dynamic API analysis to succeed for coffi. All of our guinea pig libs passed API analysis with JDK23. I should probably step away from the computer... I've been at it all day! But I think I can deploy something tomorrow that will allow coffi's docs to build properly on cljdoc.

That's good to hear!

Hey ho @suskeyhose, I upgraded the cljdoc-analyzer builder to use JDK23, and coffi now passes API analysis: https://cljdoc.org/d/org.suskalo/coffi/1.0.486

Awesome!