This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-04
Channels
- # aatree (5)
- # admin-announcements (37)
- # alda (1)
- # announcements (4)
- # architecture (1)
- # aws (3)
- # beginners (82)
- # boot (230)
- # braid-chat (14)
- # cider (48)
- # cljs-dev (8)
- # cljsrn (31)
- # clojars (47)
- # clojure (72)
- # clojure-austin (2)
- # clojure-russia (396)
- # clojurescript (72)
- # community-development (3)
- # component (6)
- # core-async (6)
- # cursive (26)
- # datomic (42)
- # emacs (6)
- # events (35)
- # hoplon (57)
- # immutant (3)
- # jobs (2)
- # jobs-discuss (10)
- # ldnclj (16)
- # luminus (2)
- # off-topic (50)
- # om (181)
- # parinfer (285)
- # proton (68)
- # re-frame (19)
- # reagent (2)
- # ring-swagger (23)
- # yada (36)
Hello, I’m somewhat new to boot. Aiming to move a release process to boot over the coming days; e.g. versioning, git flow branching/tagging, building an RPM with redline RPM etc. Any pointers or examples of prior work would be appreciated
I’m new to boot and trying to pull down a dependency on the jdbc-postgres driver. it’s giving me this error message:
Line 7 of your build.boot
perhaps? A deftask
with incorrect argument declarations?
Hello guys, is there a reason why (exit-error)
and (exit-ok)
always spit out the stacktrace (even when I use exit-ok
)?
Summary
Ran 6 tests, 10 assertions, 0 failures, 0 errors
clojure.lang.ExceptionInfo: boot.App$Exit: 0
data: {:file "/tmp/boot.user2127203706560941948.clj", :line 19}
java.util.concurrent.ExecutionException: boot.App$Exit: 0
boot.App$Exit: 0
boot.task-helpers/fn/fn/fn/fn/fn task_helpers.clj: 264
boot.task-helpers/fn/fn/fn/fn task_helpers.clj: 264
boot.task-helpers/fn/fn/fn/fn task_helpers.clj: 244
If someone wants to try, it is in sift-fix-test
branch in my repoYeah, I was a bit puzzled by that too... https://clojurians.slack.com/archives/boot/p1454555793002583
so @seancorfield I cannot see the discussion, is there an issue open somewhere?
I asked about those functions back when I was working on boot-expectations
. I was surprised (exit-ok)
generated an exception. I don't recall what @micha said but it does seem that exiting with an exception is "idiomatic"...
At least exiting with an exception on failure.
but if with return 0 ?
It's very weird to exit with an exception when exiting with a zero status...
I don't think I've seen other tasks actually do that tho'...
yeah maybe we can improve on that, I saw there is some kind of catching and retroving here https://github.com/arichiardi/boot/blob/sift-fix-test/boot/pod/src/boot/util.clj#L221
and that line prints the exception
because from somewhere it receives a ex-info
wrapping a App.Exit
so maybe it is some sort of issue
@micha https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L309 would this delay stop the get-env from evaluating until the fileset passes through?
https://clojars.org/io.dominic/boot-cljs I've just used my personal deployment in the edge repo, so, yay!
@micha for the repl, I created a pod, and passed it along as an argument to the repl task.
@dominicm: that delay in the repl task probably needs to be fixed, i think you're right there
@micha https://github.com/juxt/edge/blob/master/build.boot#L72 where I ended up with the repl task
your build.boot there is like a tour of boot internals and how to make it do what you want
heh, boot is pretty powerful, and not too far from being flexible. We've definitely achieved something neat.
So, I was creating my pod, and then passing it's name to core/launch-nrepl, but as the pod was going out of scope, the pod was being destroyed. And as the repl runs "with-pass-thru" it waits until other tasks have finished to run (I think?), so it delays, and the pod can't be held onto. (or maybe it can?) So yeah, I just figured it was easier to go direct.
you can avoid the pod falling out of scope by keeping a reference to it, in an atom perhaps
boot.user=> (def server-pod (doto (boot.pod/make-pod boot.pod/env) (.setName "server-pod")))
#'boot.user/server-pod
boot.user=> (launch-nrepl :pod "server-pod" :server true)
nREPL server started on port 55459 on host 127.0.0.1 -
#object[boot.core$launch_nrepl$fn__1086 0x45699404 "boot.core$launch_nrepl$fn__1086@45699404"]
Yeah, I wasn't sure if that was much less of a hack. Fortunately the repl/launch-nrepl function takes the same params as core, pretty much.
@micha about the stack trace when boot returns zero...is there anything we can do about it ?
clojure.lang.ExceptionInfo: boot.App$Exit: 0
data: {:file "/tmp/boot.user2613241006960267934.clj", :line 19}
java.util.concurrent.ExecutionException: boot.App$Exit: 0
boot.App$Exit: 0
richiardiandrea [8:45 PM]
yeah maybe we can improve on that, I saw there is some kind of catching and retroving here https://github.com/arichiardi/boot/blob/sift-fix-test/boot/pod/src/boot/util.clj#L221
[8:46]
and that line prints the exception
[8:46]
because from somewhere it receives a ex-info
wrapping a App.Exit
I tracked it down to that part by println in both branches of exit-ok
exiting for the final time, it chooses the false
branch
creating a runnable uberjar, but can't start it due to Caused by: java.lang.ClassNotFoundException: java.util, compiling:(clojure/tools/reader/default_data_readers.clj:1:2)
https://gist.github.com/tolitius/5f1dc640977f6a5ee101
I am converting the project from lein
, so I must be missing something.
@tolitius: do you have a dependency on clojure in your build.boot somewhere? because you need one to get bundled in the jar
if you do jar tf target/stream-on.jar
do you see all the things it's suppsoeed to have in there?
@tolitius: https://github.com/adzerk-oss/boot-ubermain might interest you also
since uber has gotten faster the 'exploder' part isn't really necessary anymore, but i do recommend the Java proxy approach so you don't have to aot
@alandipert: great thx, I'll give it a try
so about AppExit 0 do we have an opinion, maybe an option to disable stacktrace printing?
@seancorfield had the same problem I guess, it might be an issue if you say that and I will investigate
@richiardiandrea: Do you want to open an issue in GH for tracking the AppExit 0 exception / stack trace thing?
@yenda I no longer get target directory warnings with boot 2.6.0-SNAPSHOT. And it works great now with windows 10 too. Though I still need to turn off jetty's use of mapped files.
@laforge49: have you happened to have tried the hoplon 'get started' app on win10 w/ boot 2.6.0-snapshot?
@yenda: ubermain is an experimental thing that i haven't use dmyself lately... best to stick with what works
@alandipert: Is there something special about that demo? I'm finding that EVERYTHING works now except headless JS unit tests.
@laforge49: no, and that's great! i ask because of activity on https://github.com/hoplon/hoplon/issues/80
Well, as I said, you also need to turn off jetty mapped files. Hmm. I should write this up today.
also I thought the file option will be name of the jar but it is still project.clj, not sure if this can be configured
@alandipert: adding an explicit clojure dep did not help (it actually does bring it transitively as well) for uber
taks, but simply using boot-ubermain
works great, thx
one gotcha though.. I don't think a --file
option is used: https://github.com/adzerk-oss/boot-ubermain/blob/master/clj/adzerk/boot_ubermain.clj#L22 so it always creates a project.jar
regardless of :file "foo.jar"
option
Running on windows: https://github.com/hoplon/hoplon/wiki/Running-on-Windows
I made a pull request https://github.com/adzerk-oss/boot-ubermain/pull/1
also wouldn't it be better for api consistency to have the same signature for the main function as the jar function ?
I mean having the option like that :main 'burp_clj.core instead of :main-var burp-clj.core
@tolitius: ok i think the problem might be with the :main arg to jar
it takes a class, not a var sym
@tolitius: so i think it should be :main 'stream_on.app
maybe
since AOT-ing munges
I'll drop the old page on hoplon and change the reference in getting started to point to the new page.
@tolitius: i am remembering this with the help of https://github.com/adzerk-oss/boot-uberjar-example that i also haven't touched in awhile
@alandipert: yep, boot-uberjar-example
is what I started from, so the :main 'stream_on.app
very well maybe it, since looking at the stacktrace, it does not look like it finds what's in main
i'm doing some hacking on castra, and have set up boot to point to my local-fork. i'm having an issue with castra not pulling in it's deps
the best way to get the dependencies to all work is to install a jar in your local maven repo
is that significantly different from boot watch pom -p foo/bar -v 1.2.3-SNAPSHOT jar install
?
@tolitius - the closest you can get out of the box is build-jar push-release
from bootlaces
@dm3: thx, yea that's what I use for my evening work but at the day job there is a dedicated build team that does not like changes that much.. so I am trying to make it as precooked as possible for them
@seancorfield: @micha see my comment in the PR, no issue, just don't call exit-ok
twice
btw, what would be the way to pass an uberjar (cooked with (uber)
or (ubermain)
) to the push task?
proposal ^
@tolitius: with the -f
and -P
flags
thanks @alandipert
sure! altho i would add uberjars in maven is usually not what you want
what are you trying to do?
usually you would not, I agree. the way things are deployed (around where I am) is using rpms
cool. yeah i worked somewhere that did the same
at some point i wanna try to get fpm running in a jruby pod
so we can have legit rpm, deb facilities
what is the difference between the uber and ubermain task btw ? is it that uber explodes all the dependencies and ubermain does not ?
@yenda: that's right, ubermain adds the deps to the classpath at runtime
@yenda: the same way eg tomcat does
since java -jar doesn't natively do anything if you have a jar with jars in it
exploding the jars at runtime makes the build faster at the expense of runtime... not a big deal in the servlet scenario usually because the app container usually adds the jars to the servlet container classpath once per deploy
for the uberjar case, imo not a win, since the uberjar is only run once
several months ago ubermain made more sense when uber
was a lot slower
now, it's a wash imo
the only fringe benefit is not needing to AOT
which is in ubermain but unrelated to the jar explode part
@micha: I was able to get the checkout working in the shell and in the build.boot
file for the demo/simple-castra
example. however after the deps are pulling down for castra, the app can't find the castra namespaces
Oh, so "user" code (tasks etc) should never call exit-ok
at all then?
I guess then the question is: should user code even call exit-error
or should it just throw an exception to exit with an error?
throwing an exception is the most composable thing imo
since previous tasks can choose to catch
@micha: nevermind, i removed the dep from the set-env! and that was what was causing problems... silly me
I think that's what I have boot-expectations
do but I should probably clean up boot-new
in that respect.
probably it was a way to exit clenly from middlewares
throwing I mean
but if we implement what I wrote in the issue, we can still take advantage of that
nonetheless this should be specified in exit-ok
and exit-error
doc, I have an open PR for documentation changes
Cool.
@pppaul: you can (reset! boot.util/verbosity 1/2/3)
but in general not too many traces
it is an atom with an int inside
those are nice to use if you make a task that others will use, because it prints the different types of messages in a consistent way
@alandipert: push
does not seem to pick up a file generated by ubermain
. tried file-regex
/ file
with absolute path.. but it looks like it gets to the push
task before ? the jar is synced with fs
(comp
(ubermain)
(target)
(push ;; :file-regex #{#"project.jar$"}
;; :file ".../stream-on/target/project.jar"
:ensure-snapshot true
:ensure-clean false
:repo-map {:url "...-snapshots"
:password "..."
:username "..."})))
@tolitius: i'll take a look later
were you not able to get normal uber to work?
no.. tried the _
thing, might need to spend more time on it.
with "ubermain / push", there is definitely something simple I am missing about how tasks chained in general, since (comp (ubermain) (target))
works fine, but (comp (ubermain) (target) (push))
ends up with an exception in ubermain:
java.util.concurrent.ExecutionException: java.lang.NullPointerException: entry
...
adzerk.boot-template/eval374/fn/fn/fn boot_template.clj: 38
adzerk.boot-ubermain/pack-jar/fn/fn boot_ubermain.clj: 12
yeah i already quizzed him on this
that's a weird error, but ubermain is also weird. and i don't remember how it worked really 😞
i'll take a look later tho
@micha: sure, not something I would normally do. the place I am working at at the moment pushes rpms to maven repos (build process, not something I can change). so the idea is to use self contained jars instead (for parts that I create)
in the meantime i recommend getting normal uber going
@alandipert: sure, thanks. I'll switch to (uber)
if i want to add some debugging namespaces to my files with boot, would i use with-pre-wrap
or one of the similarly named functions?
doc added to PR #394, btw do I need to rebase it or something?
I will rebase, now the other PR has merge conflicts, but against master, I have already rebased
oki doki
For a stable build, is it recommend to use BOOT_CLOJURE_VERSION=1.7.0
or BOOT_CLOJURE_VERSION=1.8.0
in build.boot
with boot version 2.5.5
?