This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-21
Channels
- # announcements (24)
- # aws (2)
- # babashka (20)
- # beginners (147)
- # cider (20)
- # clara (43)
- # clj-kondo (3)
- # cljdoc (15)
- # cljsjs (1)
- # cljsrn (36)
- # clojars (19)
- # clojure (64)
- # clojure-europe (4)
- # clojure-italy (45)
- # clojure-nl (1)
- # clojure-spec (20)
- # clojure-uk (26)
- # clojurescript (16)
- # cursive (9)
- # datomic (18)
- # dirac (14)
- # docker (3)
- # fulcro (48)
- # keechma (1)
- # leiningen (32)
- # luminus (1)
- # off-topic (40)
- # pedestal (1)
- # quil (1)
- # re-frame (24)
- # reagent (3)
- # reitit (3)
- # remote-jobs (2)
- # ring-swagger (4)
- # shadow-cljs (115)
- # spacemacs (22)
- # specter (4)
- # tools-deps (76)
Has anyone here ever managed to get Snyk to scan a Clojure project using tools.deps for vulnerabilities? I’m giving it a try and Snyk is helping out but I’m running into Maven problems.
[ERROR] Failed to execute goal on project project: Could not resolve dependencies for project project:project:jar:0.1.0: The following artifacts could not be resolved: com.gfredericks:test.chuck:jar:0.2.10, clj-commons:clj-yaml:jar:0.7.0, hawk:hawk:jar:0.2.11: Could not find artifact com.gfredericks:test.chuck:jar:0.2.10 in central () -> [Help 1]
I thought maybe I was running into this: https://github.com/snyk/snyk/issues/207
But I checked and the pom.xml
generated by clojure -Spom
already includes both Central and Clojars.
could you post the pom?/
I'm trying to remember if it's supposed to do that now or not
looks like it is, so might be broken
I guess it will only right now add repos explicitly listed in the deps.edn
I'm looking at it
ah, it's subtle but I see the problem
any possible workaround? Or maybe I should brush up on my sed
skills and try to just patch the pom
for now?
for the moment you'll need to manually modify your pom.xml after gen
nah, I've got it
fixed for next release, but not sure when that will be (and added a test for future)
Is there a way to get tools.deps to print out all of the :paths and :extra-paths that a given set of aliases resolve to?
-Sdescribe
prints out some information, but nothing about the composed config
not currently, although I've been making my way towards making something like that possible
I've wanted something like mvn help:effective-pom
so that's been a back burner project of mine
do you care about :paths vs :extra-paths?
All local paths for my usage (send them to clj-kondo)
ok, that's good
Does anyone know if there’s an uberjar library for tools.deps that supports merging of files like data_readers.clj
?
I looked into depstar, but it looks like it has hardcoded that part. I could submit a PR, but I was hoping there was something around already.
have you tested it @weavejester ?
Yeah, that’s what I mean by it being hard-coded, @ghadi.
Notice data_readers.clj
is explicitly checked for.
And clash-strategy
doesn’t look like it can be overridden.
@weavejester pack avoids merging altogether.
@weavejester Happy to entertain PRs on depstar
to extend the clash handling logic. I inherited that as-is and haven't enhanced that part yet...
Are there any disadvantages to Capsule jars? I guess I’m inherently wary of anything that builds on known deployment mechanisms.
They use a little bit more memory because they start trampoline jvm, much like lein does
You might also want to consider the docker mode, which will directly create a docker image.
@U09LZR36F can I package a clojure project into a docker image?
@U09LZR36F can you share your workflow?
@U0NBGRGD6 My understanding is that you provide a docker registry and it will upload it there. People are using it with Google.
@weavejester: Yes there are definite disadvantages to capsule jars… Also they extra the jars contents into a cache to build the classpath. You also get a jvm dance at startup; and you then need to care about proxying various JVM options to the real app vm; i.e. if you want to set the heap etc. I’ve been meaning to look at onejar as an alternative. FWIW in spite of the occaisional frustration we currently avoid the issue you’re on about with capsule jars. I think there’s an argument that merging the files has problems too; it would be better to resolve all of them at runtime; i.e. uberjars are really just a hack. I just wish the JVM platform itself supported this.
It might just be better to zip up the classpath and write it in a shell script that starts the jvm tbh.
IIRC I wrote this stuff up on a duct issue somewhere… 👀
Also lein-tools-deps and using lein for just the packaging and deployment may also be a solution for you. (Full disclosure: I wrote it)
If I had control over how people deployed, I'd tell them to use the skinny mode, aka, dump my project into a folder