Just ran into the same problem here, however pinning the jetty-server version didn’t
fully resolve it for me. Instead of going down the dependency/classloading rabbit hole, I just decided to use Immutant instead, mostly since that’s what they picked for Luminus, so I could use their setup as a guide.
I think this issue will be common since a sensible path of least resistance if you’re developing a web app is to use Ring with the included Jetty adapter, which is a different version than the one com.datomic/client-cloud is using (you can see via clojure -A:dev -Stree if you’re setting up deps.edn similar to the guides).
Pinning the jetty-server version as explained above worked because it causes the dependency resolution algorithm (Maven’s I guess?) to prevent ring-jetty-adapter from bringing in it’s conflicting version. The version you explicitly asked for takes precedence and excludes the implicit/transitive one. I’m not sure if it being the newer version makes any difference. If you run clojure -A:dev -Stree again, you’ll notice that ring/ring-jetty-adapter no longer lists any sub-dependencies of its own once you pick the jetty-server you want.
Gaining a full understanding of JVM classloading details is hard, but by default (eg when you’re not using OSGi or some other framework with a non-standard classloading process) loading the same class more than once in the same JVM is risky and usually leads to these kinds of errors.