This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-15
Channels
- # admin-announcements (3)
- # architecture (2)
- # beginners (54)
- # boot (85)
- # braveandtrue (8)
- # cider (21)
- # cljs-dev (56)
- # cljs-site (5)
- # cljsjs (15)
- # cljsrn (9)
- # clojars (4)
- # clojure (99)
- # clojure-austin (1)
- # clojure-russia (36)
- # clojure-spec (53)
- # clojure-uk (29)
- # clojurescript (161)
- # datomic (8)
- # hoplon (3)
- # immutant (48)
- # jobs (1)
- # jobs-rus (1)
- # leiningen (10)
- # om (23)
- # om-next (1)
- # onyx (22)
- # parinfer (3)
- # planck (13)
- # protorepl (8)
- # re-frame (46)
- # reagent (2)
- # remote-jobs (1)
- # respo (1)
- # specter (5)
- # testing (12)
- # untangled (50)
- # yada (13)
I am trying to get boot approved in an environment with private, locked down, maven repositories, and I am encountering a problem where boot seems to dynamically need clojars on the fly
In particular, the aot
task seems to want to hit Clojars
I have narrowed this down to the following line:
(future (pod/make-pod (core/get-env)))
if clojars is not listed in :repositories, this causes
ArtifactNotFoundException Could not find artifact boot:pod:jar:2.6.0 in ...
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap (WagonRepositoryConnector.java:947)
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap (WagonRepositoryConnector.java:941)
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run (WagonRepositoryConnector.java:669)
org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run (RunnableErrorForwarder.java:60)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
java.lang.Thread.run (Thread.java:745)
repro:
;; sneaky clojars consumption?
(set-env! :repositories [["central" {:url " "}]])
(require '[boot.pod :as pod]
'[boot.core :as core])
(def pref (future (pod/make-pod (core/get-env))))
@pref
^^ ok, so that seems to end up down at aether/resolve-dependencies
I don’t think aot compilation (or any task that is not specifically about deps) should talk to maven repos
Hm, this might be fixable by passing :retrieve false
to aether calls used by aot
Is this kind of aether use common elsewhere in boot?
@stuarthalloway: Is this the first execution of boot on the current machine? I believe the boot binary bootstraps on first exec, downloading the rest of boot. So I think you would see that behavior with any task call, not just aot
Try the repro
no matter how many times you run it, aot makes a network call
even if everything is locally resolved already
Ah, yes, I see the same behavior here. The issue is likely aether's repository checking
it stores the repository where it pulled the artifact from in ~/.m2/repository/boot/pod/2.6.0/_maven.repositories
, then, when loading that artifact, it confirms that one of the repos listed there is in :repositories
definitely wrong behavior for a task named aot
it's not the aot task, it's boot trying to build it's classpath - it asks aether for the jars for its deps, and it triggers this
would :retrieve false
not be the right thing in all aot
cases
you can tell aether to ask only for jars it already has cached locally
and some pre-aot step should be responsible for talking over the network
your viewpoint looks upside down 🙂
the repository tracking is a security feature - aether may still check that with :retrieve false
. If so, it may still fail to use the artifact on disk, but I haven't tested that
yeah. 😞 If that cannot be avoided aether is unsuitable for the job of building classpaths
almost everything about aether is pluggable. I would be surprised if there is not something that could be done.
true also about boot 🙂
aot is a tiny task, you could easily make your own that doesn't even use a pod
it definitely does make sense to me to eliminate pod dep resolution where we can in boot though
the other thing you can do is deploy boot jars to yuor private maven server
when i was at Big Corp we had to do this for auditing anyway
New ClojureScript site is up. Boot is still missing on tools / guides page. http://clojurescript.org/tools
@alandipert: yes, my current plan is to write our own just-the-aot-please
task, but switching to a :retrieve false
in boot is worth investigating
@borkdude: please submit an issue or a PR to add it!
@alandipert the “deploy boot jars to your server” makes sense but is tricky if one cannot enumerate the tasks that might talk over the network, e.g. i would not expect aot
to fail in an environment with no network connectivity
@alandipert should I make a ticket?
agreed, which is why i think you're right and that we should try to fix for boot
in the general case of open-world tasks tho it's insoluble
sure, please do
@stuarthalloway: I think you will need to have a fresh maven cache and set the BOOT_CLOJARS_REPO
, BOOT_MAVEN_CENTRAL_REPO
env vars
if your local mavan cache contains artifacts from clojars, aether will need to talk to clojars sometimes
also if you want to lock the build down to specific repos you don't want artifacts from clojars in your cache
once you have a maven coordinate cached in your .m2, aether will pin that coordinate to the repo you got it from
that all makes sense, except the “need to talk to the repo again” part. If all the deps are local, there should be a way to avoid that
admittedly if aether does not expose that we are kinda stuck
I will be testing this later today
I will reserve judgment until I know what it does 🙂
it would be good to establish a best practices guide to locking boot down, i will start a wiki page
I can’t get boot-cljs
to work with closure defines. Anyone has run into the same issue? I tried both in the main.cljs.edn
{:require [env.android.main]
:init-fns [env.android.main/main]
:compiler-options {:optimizations :none
:closure-defines {’my.ns/platform ”android"}}}
as well as directly in the task
(cljs :compiler-options {:optimizations :none
:closure-defines {”my.ns.platform” "android"}}
:ids #{"main”})
:closure-defines {"goog.LOCALE" "fi"}
this is working fine for me
Not sure how self defined vars work
@vikeri: an alternative to gcl defines: https://github.com/adzerk-oss/env
Great! My use case is parametrizing android vs ios builds. I’ve had issues with goog-define before. So I’ll try that lib.
is there an option to pass a (Java) property to boot repl
?
perfect
thanks
@micha: Implemented! Not entirely clear how to use is from the readme but I figured it out.
@bsima: You can specify multiple different targets using the target
task, this way you can create tasks for different builds