that package is absolut horror and I do not recommend using it with shadow-cljs

you can use webpack for the JS deps via https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider-external

also don't follow a react-native guide when you are building a webapp?

thanks for the link @U05224H0W I’ll try that

Summary of issue: java.lang.NoClassDefFoundError: com/google/common/collect/Streams

Relevant classpath trace:

So, the conflict is between

io.github.clojure/tools.build 0.9.5
  . org.clojure/tools.deps 0.18.1354
    . com.google.guava/guava 31.1-android :newer-version

thheller/shadow-cljs 2.25.2
  X org.clojure/clojurescript 1.11.60 :use-top
  . com.google.javascript/closure-compiler-unshaded v20230411
    X com.google.guava/guava 31.0.1-jre :superseded

In the past, I have worked around by including com.google.guava/guava {:mvn/version "31.1-jre"} in project deps

However, this also works, and seems to be the better fix: io.github.clojure/tools.build {:mvn/version "0.9.5" :exclusions [com.google.guava/guava #_ 31.1-android]}

Commenting here because I've read all the historical threads and don't recall anyone getting this far. Maybe I have made a mistake

well the solutions vary because the source of guava differs

but I have advised with solution many times in many threads as that is a rather frequent problem

For the record, the theller guidance is to shell out to shadow to limit classpath contaminataion

I still don't know why none android libs depends on the guava android variant

this one looks to me like a mistake in tools.build

I have also suggested pinning the specific version in your own deps or adding exclusions, but yes best option is to keep the classpath clean

pretty sure it isn't tools.build depending on it directly, rather some maven lib

I can't tell yet if clean classpath is a real solution because, due to clojurescript macroexpansion, shadow requires app classpath to build

correct, but that likely doesn't need tools.build? 😛

what the fuck https://github.com/clojure/tools.deps/blob/master/deps.edn#L14 com.google.guava/guava {:mvn/version "31.1-android"} ;; update transitive dep due to CVE-2020-8908 https://nvd.nist.gov/vuln/detail/CVE-2020-8908

oh yikes it does

here is the original commit https://github.com/clojure/tools.deps/commit/4f848c920d4905d84263ab27c097ce623daa0aed

and the reason I guess

I wonder if its an acceptable fix to just have shadow-cljs depend on a newer guava version again 😛

that CVE is years old, the override can likely be removed, and it's unclear if the override was ever correct

it used to when the closure compiler didn't declare it correctly, but thats not really a fix as long as a android variant is arround

just checked https://mvnrepository.com/artifact/org.apache.maven/maven-core/3.9.4 and it still has a bunch of CVEs, not sure if they are the same though

afaict shadow depends on the correct guava version right now, shadow is doing the right thing

shadow currently doesn't depend on it, the closure compiler does

ah

but with an "older" version, thus getting replaced by the android variant

thheller/shadow-cljs 2.25.2
  X org.clojure/clojurescript 1.11.60 :use-top
  . com.google.javascript/closure-compiler-unshaded v20230411
    X com.google.guava/guava 31.0.1-jre :superseded

copy paste error

guava is the #1 dependency conflict source by a very wide margin, like 99%

Now I understand - yes, if shadow depends directly on an upgraded guava (to a backwards compat version that is newer) - it would take precedence

so might make sense for shadow-cljs to force a known compatible version that "defeats" the common known android variants

datomic also brings an incompatible guava, so that was the other common source

looks like it is getting killed by OOM killer

should be something in your system looks about the process getting killed?

Yeah, that looks like it's the issue. /var/log/kern.log is showing plenty of Out of memory: Killed process 6432 (java)

is your server a virtual machine? which java version do you use?

yeah, it's the minimal DO droplet; java 11.0.20

tried adding :jvm-opts ["-Xmx512M"] to [:builds :app]

that is not a valid option in the build config itself, only at the shadow-cljs.edn root

try upgrading the java version, that might also just fix it

11 still had the bug of allocation memory based on host not vm

thanks, moved jvm-opts to root and upgraded java to 18

Still failing due to OOM, using

{:source-paths ["src"]
 :dependencies []
 :dev-http {8080 "target/"}
 :jvm-opts ["-Xmx256M"]
 :builds {:app {:output-dir "target/"
                :asset-path "."
                :target :browser
                :modules {:main {:init-fn app.main/main!}}}}}

why compile on the server in the first place?

compile locally and rsync the output to the server or something?

how much memory do you have? I mean 256M is already probably too low

I want this compile to happen as part of CI. I guess I could build on CI and then rsync the result to the server ...

only 1G mem

well the CI already probably uses 50% of that RAM for itself, so you are kinda fighting the limited resources a bit 😛

sorry, I meant a CI service (I'm using circleci)

ah, sure that works. also a known OOM killer though 😉

ok, resizing the droplet to 4G memory did the trick! Thanks for the advice here