Does anyone know of a worked example of integrating Java sources into a tools.deps project like https://github.com/puredanger/clojure-from-java, ideally with support for iterative development/reloading of the Java files?
I understand there's no equivalent of :java-source-paths
in deps.edn and we have to do some sort of jar compilation step manually
https://github.com/xapix-io/axel-f/tree/master/src/axel_f/buddy/util
small example
to compile - javac $(find . -name '*.java' -type f)
Not sure whether this is the best channel for this question, but: I've inherited a codebase that makes heavy use of :pre
and :post
. The project currently uses Leiningen, where it's possible to disable assertions when building an uberjar by adding :global-vars {*assert* false}
into project.clj
. Is there a way to disable assertions with tools.deps?
How does leiningen implement this feature?
How to let deps list all the direct and indirect jar dependencies of a project ?
No idea. Could look into it. Might be it just does alter-var-root
on *assert*
at the start.
$ bb -e '(run! println (babashka.classpath/split-classpath (with-out-str (babashka.deps/clojure ["-Spath"]))))'
src
/Users/borkdude/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar
/Users/borkdude/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar
/Users/borkdude/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar
clj -Stree
?
It'd be nice if there were a system property to disable assertions.
I still don't see how leiningen sets the dynamic var for each namespace, or does it establish thread bindings for the entire project, I guess so
Yeah, not sure.
Looks like my best bet is to bite the bullet and migrate to spec/assert
(most of the pre/post conditions are spec assertions).
(Or fdef
.)
or wait for spec2 ;)
I'm afraid I'll need to deliver before that. š
Thanks for the -Stree. Didnāt find that in man clojure
on mac. But that option exists in clj -h.
Since you mentioned list
I thought you were looking for a flat list instead of -Stree
:)
clj -Stree | tr ':' '\n'
Why do you want to disable the assertions? That would mean that if your code tripped over those conditions in production, it would continue on with bad data and potentially cause all sorts of corruption, instead of failing fast.
Iāve never understood why folks want to disable assertions in productionā¦
It depends if you use those assertions for dev purposes or domain purposes. We use asserts for dev purposes e.g. to verify if our system has the right components in certain function calls
@seancorfield This codebase is absolutely chock full of pre/post-conditions. Most every function has one. If we enabled them in production, the application would be slow as molasses. It would be a different matter if there were assertions only at the boundaries of the system.
Ugh! Thatās a poor use of asserts IMO. Doesnāt surprise me though, really. Sorry.
100% agreed.