@U7KPK060K Unfortunately Java libraries with custom classes don't work with bb, unless they are built into bb. This restriction comes from GraalVM native-image. Ways to work around this: 1. shell out to another program which can do the task you are after 2. write a babashka pod that wraps the Java library 3. use #nbb which is similar to #babashka but gives access to all Node.js libraries without any restrictions 4. Or of course, just use JVM Clojure

Ok thanks, thought that might be the case

Let me try to make a quick nbb example (just for my own curiosity)

@U7KPK060K I made this example in #nbb https://github.com/borkdude/nbb/blob/main/examples/pdfjs/example.cljs FWIW :)

Haha I just setup the same thing but with jvm clojure and it took over a minute to run (on a fast machine!) Your nbb demo takes like 3 seconds, it's a great use case for it I think

Thanks for putting that together!!

does java.security.MessageDigest work for you?

Whoops, its there? 😲 So appears only parts of javax.securityare missing. Thought it is the whole package due to.

user=> (require 'digest)   
java.lang.Exception: Unable to resolve classname: java.security.Provider [at digest.clj:6:3]
user=> 

@U06FLL69W Ah you mean, you want to load the Clojure library digest?

I didn't understand that :)

Let me see what I can do about this

Yes, was just trying the library and hoping for the best. Already shelling out to sha1sum, but that's a bit ugly. 😂

@U06FLL69W you can just use interop on MessageDigest directly

but I forked the library and made it babashka compatible now: https://github.com/babashka/clj-digest

Both the Providers and Security class were missing but you don't actually need them

This commit did the trick: https://github.com/babashka/clj-digest/commit/b4a30c2848dc9bd1f8ea7265b9b262e552f97929

Awesome! Thanks!

I think it would be quite convenient to include this library in bb itself maybe

I think its footprint does not hurt. 😉

I added the necessary classes to bb now so the original library can also be run from source in the future

Was about to ask whether adding deps.edn is worth the hassle. 😂

ah hm

it doesn't have one?

I will take care of this once the library is migrated to clj-commons

I added it to the fork now

Awesome. Pulling it in via deps works now. deps should probably default to {}instead of complaining Manifest type not detected 😉 /cc @U064X3EF3

you can do this yourself btw by adding :deps/manifest :deps to your lib map

That kind of looks to me like it isn't parallel but sequential?

The thing is that this two tasks are blocking: 1. shadow-cljs watch app 2. webpack server

Without parallel the second task will be never started, right?

ah right

so what you want to do is babashka.wait/wait-for-file

and then start the second one

I think

ok thanks, I try this!

oh it's wait-for-path: https://github.com/babashka/babashka/blob/8b8ba47f65b8c392b367d6b164bd84f5c1bd6d39/src/babashka/wait.clj#L73

so you can do that in a task as well. wait for the path and then start webpack

Cool thanks

It works perfectly thanks!

{:tasks
 {:requires
  ([babashka.wait :refer [wait-for-path]])
  dev {:doc ""
       :task (run '-dev {:parallel true})}
  -dev {:depends [dev:cljs dev:webpack]}
  dev:cljs {:doc "Runs Shadow-cljs watch"
            :task (shell "npx shadow-cljs watch app")}
  dev:webpack {:doc "Runs Webpack dev server"
               :task (when (wait-for-path "target/index.js")
                       (shell "npx webpack server -c webpack.config.js"))}}}

Awesome! Go forth and spread the word :)

@U9ES37CSZ This is currently not yet supported (similar to how you cannot do this with Makefiles). But you can have one root bb.edn and use :dir to execute shell and clojure commands in subdirectories, if that helps

(shell {:dir "project1"} "do-something") (clojure {:dir "project2"} "-M:foobar")

The other option is to split out common code into a library and use :local/root to share that code between projects

and then hook that up to your project-specific bb.edn

Thank you for the ideas @U04V15CAJ 🙏