Hey so I have a new project that I've just made my first clojars release for, but I don't want to mention it in #announcements until the cljdoc for it builds, if that's possible. It might not be, so I might have to go to like codox, but I'd like to avoid that. Could I get someone to check out https://cljdoc.org/d/org.suskalo/coffi/0.1.169/doc/readme ?

The build failed because this project depends on classes from JDK 17, and it depends on the jdk.incubator.foreign module.

Is there any chance this can be supported soon? If not, I'll need to look into another online docs option for this project.

@suskeyhose Hmmm... interesting, I do remember checking what JDK the cljdoc analysis job used over at CircleCI a while ago. And it was JDK 11. Just did a little digging now and it turns out the image we are using is now considered as "legacy" by CircleCI. The current replacements are "convenience" images but there is nothing Clojure specific anymore. There is an OpenJDK convenience image though which includes JDK 17 tags. I suppose we should check out what best practice is now for Clojure on CircleCI.

But since JDK 17 is so new, I guess we'd want to first check that it works as JDK 11 did for cljdoc. Anything special we'd need to do?

I don't think there's anything in particular that would need to change from java 11 to 17, all my clojure apps work fine on 17 except for http-kit's sni client

The big thing for my library though is it needs all unnamed modules to be able to access jdk.incubator.foreign, and that module needs included.

Honestly, we would have probably been auto-upgraded to 17 had our circle image not gone legacy.... But that doesn't mean we shouldn't have a careful read through the release notes to see what might affect us (probably nothing, yeah? but good to be aware).

For sure.

This seems like a good opportunity to offer a configuration (somehow) that specifies the primary version of the JVM to use when ingesting and processing code?

(at work we're juggling with some code that must run on JDK8 -- I know! -- and other code that must run on JDK11 but we're already testing against JDK17)

Yeah, we have an open issue to optionally support JDK11 in addition to JDK8 - but then we realized we were already on JDK11! (our CircleCI image tag was not specific and we were auto-upgraded). Have not (yet) heard of a need to specifically build docs on JDK8 (not saying there is not one, just have not heard one). The issue also discussed specifying arbitrary JDKs. That issue has not gotten any interest in a while though, so maybe the community does not really need it?

Here's the issue: https://github.com/cljdoc/cljdoc/issues/275

"(just FYI, since depstar was mentioned: I have no plans to tackle AOT or manifests in depstar and just closed that issue out as "won't do")" -- oh, that did not age well 😞

Just an example of you being open to change @seancorfield!

What's the status on paying attention to -cljdoc tags first?

@suskeyhose are you referring to https://github.com/cljdoc/cljdoc/issues/459? I started on this by first looking at this issue https://github.com/cljdoc/cljdoc/issues/468 but then got entirely distracted by other work.

I mean that I would like to be able to have the cljdoc of my readme have a correct sha and tag in it for the source dep, and that can't be done if cljdoc pulls from the tag on clojars. 🙂

What we'd discussed before was for it to look at tags with -cljdoc at the end first if they exist to pull things like articles.

Yeah I think you are referring to https://github.com/cljdoc/cljdoc/issues/459.

yes

I’ve not had a chance to get back to working on that issue yet.

fair enough.