Hi, I have a couple of old ClojureScript projects that don’t build anymore: the Parinfer site and talk from conj 2017. I’m demoralized a bit that I now have to debug an old build process for code that hasn’t been touched in 5–7 years. Is there something I’m missing about freezing version numbers for tools and/or transitive dependencies? And anecdotally, have y’all had similar troubles resurrecting old cljs builds?
You might need to share at least some of the config files for those projects and how exactly you are trying to build them (and what errors you get)…
If you’re relying on a tool that is installed outside your project, you could have updated it in the meantime, and need to either roll back to the version you had then or update your projects. The downside of using a tool that isn’t versioned/controlled by your project…
Is this the error you’re running into?
Exception in thread “main” java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter, compiling:(cljs/closure.clj:1:1)
Those classes were removed in Java 9, I think. Stick w/ Java 8, or bump your dependencies.
If I explicitly use a Java 8 JDK, it builds successfully:
➜ site git:(master) jenv shell 1.8 ➜ site git:(master) jenv exec lein cljsbuild once min Compiling ClojureScript... Compiling "resources/public/js/compiled/parinfer-site.js" from ["src"]... WARNING: Use of undeclared Var parinfer-site.core/number at line 321 /Users/jonathan/git/parinfer/site/src/parinfer_site/core.cljs WARNING: Use of undeclared Var parinfer-site.core/number at line 321 /Users/jonathan/git/parinfer/site/src/parinfer_site/core.cljs Successfully compiled "resources/public/js/compiled/parinfer-site.js" in 30.359 seconds.
It is not required to stick with JDK8. It was just a dependency that shipped with JDK8, but no longer does with newer versions. You now just get it as a regular dependency instead.
So, just adding
[javax.xml.bind/jaxb-api "2.3.1"] as a dependency allows you to use any JDK version (it also works with JDK8).
Like the JDK you use, I guess
Thank you for trying out the builds I linked! The config files were there, but I have since forgotten the version of lein and JDK I used. I will be tracking a jenv
.java-version file now in projects, though I’m not sure how to track versions of tools like lein or clj. Maybe this is what docker is for.
Thanks @jlfischer, JDK8 fixed the parinfer build, glad I can compile a release version again!
lein figwheel is still broken (error below). I can’t remember which version of lein I was using if that was important. And I suppose I can add the nrepl dependency to fix the error— but I’m not sure why I have to. Lein-figwheel 0.4.0’s usage notes don’t mention needing it.
$ lein figwheel Exception in thread "main" java.io.FileNotFoundException: Could not locate clojure/tools/nrepl/server__init.class or clojure/tools/nrepl/server.clj on classpath., compiling:(figwheel_sidecar/repl.clj:1:1)
$ npx shadow-cljs compile shadow-cljs - config: /Users/shaun/code/conj-talk-2017/shadow-cljs.edn version: 2.0.42 shadow-cljs - updating dependencies shadow-cljs - dependency update failed - Failed to collect dependencies for [#object[org.sonatype.aether.graph.Dependency 0x3fc9dfc5 "thheller:shadow-cljs:jar:2.0.42 (compile)"] #object[org.sonatype.aether.graph.Dependency 0x40258c2f "binaryage:oops:jar:0.5.6 (compile)"] #object[org.sonatype.aether.graph.Dependency 0x2cac4385 "quil:quil:jar:2.6.0 (compile)"]]
FWIW I cloned your conj-talk-2017 repo and was able to build it after updating the shadow-cljs version to the current 2.20.2 in the package.json (I got the same error you did on 2.0.42 and don’t have any insight as to why)
Thanks! I had to update the
.java-version file too, but it works now. I’m not yet sure how to avoid this in the future.
The version is just too old. It fails downloading because at some point (~ 3years ago) clojars.org changed its maven repo URL from
https://repo.clojars.org. The version you had used the old one which doesn’t seem to be accessible anymore, and thus fails downloading the dependencies. The error is not great but thats what was going on.
New version takes care of it.
Side note: those of us on Apple Silicon platforms, e.g. M1 macs, do not have access to jdk 1.8, at least as far as Homebrew is concerned. java 11 seems to be the minimally viable platform.
Second sidenote: rapid API evolution of Scala forced me to abandon working with it a long time ago.
I’m pretty sure that’s because Homebrew only packages the M1 native JDKs on M1. You can still download an x86 Java 8 JDK from someplace like Adoptium and it works fine. (My primary application still deploys on Java 8, so that’s what I have to keep around.)
I’ll attempt booting intel java 8 and see.
That did it. I had a JDK 1.8 already in /Library, so modifying the shell script did the trick.