Clojurians Log v2

Hi Bootleggers, I hope this helps someone: I published a little Cljs tool that translates boot-clj and Leiningen :dependencies to the newer deps.edn format: https://theronic.github.io/depsy/ (source on GitHub).

I don't think :scope applies in deps.edn

it should probably generate a test alias or something

Well, :scope does apply but the Maven libraries don't handle it in the way you might expect in all cases 🙂 The recommendation is to not use :scope and, as @dominicm says, to use aliases instead.

Is anyone testing Boot-based systems on Clojure 1.10.0 Alpha 5 or later? We tried to switch up to 1.10.0 Alpha 6 and ran into problems with pods (particularly pod refresh). We have occasionally had problems with ClassNotFoundExceptions with pods in the past -- infrequent, random occurrences which almost always go away on a subsequent run -- but with 1.10.0 Alpha 5/6 we are hitting CNFE reliably and repeatedly on a particular pod refresh in the middle of a long pipeline of tasks (that all work just fine when run independently).

For now we just backed off to 1.9.0 but at some point we'll move to 1.10.0 and just break our pipeline into separate pieces as a workaround I expect (we're looking to switch to deps.edn/CLI tooling where possible at some point, but that's currently a long way off).

sounds like a textbook case where there is a race condition that (due to a change in performance of other pieces) has suddenly been made common

I will carefully avoid pointing a finger (as it may end up pointing at me)

there are some data race detectors out there (like YourKit). I wonder if it would be possible to get any value out of them in the case that you have that sometimes fails.

The pre-1.10 failures are very rare, but also include a case I didn't mention, where loading core_instant18.clj fails -- and a subsequent run immediately succeeds. (I mention it only because of that cropping up in another classloading context the other day -- and I'm not certain it's directly related to the pod refresh issue).

With 1.10, the problem occurs only in the middle of a long task pipeline and always on a particular task setup. Since it's for a set of WebDriver-based tests against a legacy app, we don't have much motivation to fix it since we'll be decom'ing that app soon anyway (possibly before we move to 1.10).

I'm mostly just curious as to whether I'm the only person trying to use Boot pods with 1.10 "in anger" -- and whether this is a problem with Boot pods and 1.10 or a problem with our usage of Boot pods that 1.10 just makes worse...

the loading of core_instant18.clj depended on a class existence check against java.sql.Timestamp, which kinda makes you wonder if there is some sort of classloading race condition around that.

certainly I have seen race conditions around concurrent load of the same ns with state (in particular, there was an issue around clojure.spec.gen.alpha and it’s dynaloading of the test.check generators ns)

see https://dev.clojure.org/jira/browse/CLJ-2026 or the more generic case http://dev.clojure.org/jira/browse/CLJ-1406

might be interesting to try a patch from the latter in a long run to see if it changed the behavior

but I am really just fishing in the dark

Quick question: how does Clojure’s internal handling of deps (https://clojure.org/guides/deps_and_cli) fits with something like boot?