This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-04
Channels
- # announcements (5)
- # beginners (205)
- # calva (1)
- # cider (48)
- # cljs-dev (9)
- # clojure (123)
- # clojure-berlin (1)
- # clojure-europe (2)
- # clojure-italy (5)
- # clojure-nl (6)
- # clojure-russia (7)
- # clojure-serbia (1)
- # clojure-spec (8)
- # clojure-uk (33)
- # clojurescript (134)
- # cursive (5)
- # datomic (31)
- # emacs (5)
- # figwheel-main (61)
- # fulcro (10)
- # hyperfiddle (23)
- # jobs-discuss (24)
- # klipse (1)
- # lein-figwheel (3)
- # midje (5)
- # nyc (1)
- # parinfer (2)
- # pathom (14)
- # pedestal (12)
- # re-frame (46)
- # shadow-cljs (24)
- # spacemacs (1)
- # tools-deps (37)
- # vim (4)
- # yada (22)
run ssh-add -l
to see if the ssh agent is running and has an identity in it (you should get probably 1 line back)
given that it’s public, you could use the https url too, which would probably just work
if you have an ssh identity though, the likely problem areas are your /.ssh/config, or something with /.ssh/known_hosts or the host key types
I'll just switch the https for now and deal with it in the future if I need to access private repos.
FYI peeps there is a new version of lein-tools-deps
that uses 0.6.474
.
The main improvement is the TDEPS-82
fix which significantly improves runtime performance as we no longer resolve deps twice (Thanks Alex!). Also we no longer hardcode how we locate the clojure command line tool.
https://github.com/RickMoynihan/lein-tools-deps
Thank you!
I haven't used it on our major projects (leiningen, still too much hassle to switch). On new projects I'm working on boot and juxt.pack. expect for uberjar-ing boot works as expected
We switched from Boot a few months ago and our entire dev/test/build pipeline is now based on clj
/`deps.edn` and uses my fork of depstar
(which has bug fixes and also the ability to create "thin" JAR files such as you'd push to Clojars).
Yes, and deployed to Clojars for easy usage.
I’ve added javax.xml.bind/jaxb-api {:mvn/version "2.3.1"}
but I’m having this Error building classpath. Could not find artifact javax.xml.bind:jaxb-api:jar:2.3.1 in central (
:deps {br.com.vikingmakt/augustus {:mvn/version "0.1.12"}
br.com.vikingmakt/njord {:mvn/version "0.3.0"}
cheshire {:mvn/version "5.8.1"}
clj-http {:mvn/version "3.9.1"}
clj-time {:mvn/version "0.15.0"}
com.novemberain/langohr {:mvn/version "5.0.0"}
com.novemberain/monger {:mvn/version "3.5.0"}
javax.xml.bind/jaxb-api {:mvn/version "2.3.1"}
org.apache.logging.log4j/log4j-core {:mvn/version "2.11.1"}
org.clojure/clojure {:mvn/version "1.10.0"}
org.clojure/tools.logging {:mvn/version "0.4.1"}}
:mvn/repos {"central" {:url " "}
"clojars" {:url ""}}
that leading quote on “2.3.1” looks weird - maybe a smart quote? “2.3.1"
I would retype that :)
woooow…. thanks @alexmiller for some reason emacs was not showing any diff on quotes to me
when I copy pasted, it came over as quote-space in my terminal
We switched from Boot a few months ago and our entire dev/test/build pipeline is now based on clj
/`deps.edn` and uses my fork of depstar
(which has bug fixes and also the ability to create "thin" JAR files such as you'd push to Clojars).
I’m using @seancorfield ‘s depstar and it works just fine. I might want to do AOT eventually but for now it does the job.
AOT is evil. Stay away! 😇
I’ve seen you saying that before, but I’m not sure what the downsides are for things that go to production? Upside is less than half of the startup time (we went from 8s to 23s when switching from cambada to depstar).
AOT of an entire app as the last step before building an uberjar for production deployment is fine if you care about startup time.
tools.deps / clj don’t do “builds” so there is no opportunity to compile the java source
you will need to build and deploy the Java source as an artifact somewhere and depend on it that way