Fork me on GitHub
#boot
<
2016-05-10
>
jethroksy03:05:16

hey, so I'm trying to use boot-ragtime and I'm getting this error:

clojure.lang.ExceptionInfo: java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.Named
    data: {:file "/tmp/boot.user110641794411431225.clj", :line 39}
java.util.concurrent.ExecutionException: java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.Named
           java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.Named

jethroksy03:05:24

how do I go about debugging this?

jethroksy03:05:44

is there some way I can see where the error occurs?

jethroksy04:05:02

hmm looks like 0.5.2 works for me, and not 0.6.0

micha12:05:33

@jethroksy: if you do $ boot foo bar and you get an error like that with a line number, what you can do is run it again with -v option like this: $ boot -v foo bar

micha12:05:44

then you'll get a new line number where the error occurred

micha12:05:58

and then you can debug it by doing $ boot -vb foo bar

jethroksy12:05:08

@micha I think the command is run in a pod

micha12:05:10

or boot -vb foo bar |cat -n

jethroksy12:05:10

from a library

jethroksy12:05:40

I tried the -v option but it didn't show the relevant lines of the clj file

micha12:05:10

it's the -b option that shows the source of the boot.user namespace that boot generates

micha12:05:38

the -v option will cause boot to pretty print the namespace source

jethroksy12:05:40

yeah, but in build.boot all I do is (require '[foo.bar :refer [task]])

jethroksy12:05:49

I don't actually have a task definition

jethroksy12:05:50

the source looked simple enough, but I don't see any possible conflicts

micha12:05:42

it looks like maybe your require is somehow typoed

jethroksy12:05:59

hmm actually never looked at that

jethroksy12:05:49

(require '[edubot.core]
         #_'[mbuczko.boot-ragtime :refer [ragtime]]
         '[environ.boot :refer [environ]]
         '[mathias.boot-sassc :refer [sass]]
         '[seancorfield.boot-expectations :refer [expectations]])

jethroksy12:05:55

I commented it out because it didn't work

jethroksy12:05:58

but it looks fine to me?

micha12:05:24

hm yeah it looks fine to me too

jethroksy12:05:59

other commands worked, i.e. boot ragtime -g and boot ragtime -l

jethroksy12:05:18

it's just the -m that threw the error

micha12:05:41

that seems like itmight be a bug in the task then?

jethroksy12:05:48

It looks like this in ragtime's wiki:

(def config
  {:datastore  (jdbc/sql-database {:connection-uri "..."})
   :migrations (jdbc/load-resources "migrations")})

jethroksy12:05:11

so I thought passing a string wouldn't work but that doesn't seem to be the problem, and doesn't correspond to the error message I got

jethroksy12:05:12

the things I make tend to only start working a day after I build it, so I'll probably try again tomorrow and if the issue persists, i'll crate an issue there then simple_smile

therabidbanana18:05:03

I feel like this is probably easy and I'm just missing some doc somewhere for a builtin - I have 3 css files I want to combine into a single app.css - is there a built in that I could easily join all the CSS together with?

therabidbanana18:05:55

Realizing I should probably just make these imports and use the sass compiler - but still curious about how I'd accomplish the task in boot if I didn't have sass - combining all our random CSS files for plugins into a single file.

martinklepsch18:05:45

@therabidbanana: the usual approach is to write a task like concat that takes a list of files and puts them in a designated place

therabidbanana18:05:59

Okay, so I'm not missing some built-in option to sift or anything like that - I would need to create my own task?

mobileink18:05:41

hi booters. i’m back to working on boot-gae for google appengine. i have a tricky problem i can’t quite figure out. a GAE “modularlized” app is an EAR dir containing one WAR (exploded) per module. i can make it work by hand, but I’d like each module to be an independent project/dependency. so that editing would involve the standard boot watch pom jar install for the module i’m working on, but then i need a “watch-deps” task so that when a new version of a module is locally installed, it will be copied/exploded to the EAR dir. i don’t think checkout would work for this but i don’t entirely understand the checkout logic so maybe it would. i can write my own task to copy module code to EAR on change, but making the modules real modules (maven artifacts) seems much better. FWIW modules in a GAE app like this can be written in any language supported by GAE. Any suggestions?

alandipert19:05:23

@mobileink: have you messed with boot checkout? seems like what you might need

alandipert19:05:46

boot checkout -h has details

mobileink20:05:38

the problem is that the gae devserver forks it's own JVM (I think) and uses a fixed classpath. maybe there's a way with checkout, I'll have to beat on it more.

mobileink20:05:01

would boot checkout target copy the exploded jar whenever it changes?

micha20:05:47

@mobileink: i recommend the --checkouts option to boot itself in 2.6.0-SNAPSHOT over the checkout task

micha20:05:01

that will operate correctly for uberjars, target, etc

mobileink20:05:59

how do I get 2.6.0?

mobileink20:05:42

but to use checkout I need watch first, no? e.g. boot watch checkout ... I need to watch the artifact, not the source.

micha20:05:10

you can use 2.6.0-SNAPSHOT by setting bOOT_VERSION to that

micha20:05:16

then you'd do like

micha20:05:39

boot --checkouts watch task1 task2

micha20:05:20

if the artifact changes that will be propagated to the boot invokation

mobileink20:05:34

what does watch watch here?

micha20:05:43

it watches your project

micha20:05:52

and the contents of the checkouts jars

mobileink20:05:03

ah, it watches the jars, thats what i need. a key point is that a gae modularized app has no source, it's just an aggregate of other projects. so I want to use the maven coordinates of the module components as the link, to keep things clear and simple. it sounds like 2.6.0 will work for this.

mobileink20:05:29

so in effect --checkout tells watch what to watch? then the following task can copy etc. as needed?

mobileink20:05:31

Eg it could be checkout foo watch target or sth like that

mobileink20:05:09

if so it sounds like checkout adds another property to fileset items. in addition to INPUT and OUTPUT features, we have a WATCH feature. ?

micha21:05:41

@mobileink: --checkouts is a boot option in 2.6.0, not a task

micha21:05:50

it adds a new kind of dependency basically

micha21:05:24

instead of using aether to load a jar onto the classpath, it uses aether to resolve the jar but then unzips it into a directory

micha21:05:33

and adds that directory to the classpath

micha21:05:41

then it manages updating the files in there automatically

micha21:05:59

they will be updated regardless of whether you use the watch task even)

micha21:05:52

@mobileink: you still need to have the dependency in your :dependencies vector though

micha21:05:12

the --checkouts option overrides that, but the :dependencies still needs to contain the dep

micha22:05:01

the option doc is this:

micha22:05:05

-c --checkouts SYM:VER      Add checkout dependency (eg. -c foo/bar:1.2.3).

mobileink22:05:03

classpath, not fileset? so it has no effect on target

micha22:05:15

correct, unless you use the uber task or whatever you'd normally use to extract a thing from the classpath

micha22:05:09

you can use sift --add-jar foo/bar to extract it into the fileset if you like

richiardiandrea23:05:07

Is there a way at the moment to avoid the Warning version conflict detected message?

micha23:05:12

loading multiple versions of a dependency onto the classpath is never a good idea

micha23:05:30

so it doesn't seem to be good to suppress that

richiardiandrea23:05:47

mmm, yes you are right, so maybe the counter-question can be, is there a way to clean up the currently loaded classpath?

micha23:05:21

no, there's no way to remove something from the classpath once it's in the classloader

richiardiandrea23:05:04

would it be difficult to add this? Because I know that pod can achieve that, but sometimes I cannot execute stuff in a pod

richiardiandrea23:05:18

for instance boot-cljs is already executed in a pod

micha23:05:41

pods don't remove anything though

micha23:05:44

they add a new thing

micha23:05:48

which is okay

micha23:05:38

the JVM considers jar files to be immutable

micha23:05:49

so it aggressively caches things internally etc

micha23:05:03

there isn't any way around that as far as i know

micha23:05:22

you could use the --checkouts option i guess

richiardiandrea23:05:12

at the moment my boot test executes both boot-test and boot-cljs-test

richiardiandrea23:05:24

calling set-env! with the right deps

richiardiandrea23:05:36

and of course I have warnings

micha23:05:09

you could add :exclusions perhaps?

richiardiandrea23:05:40

one is:

Warning: version conflict detected: org.clojure/clojure version changes from 1.7.0 to 1.8.0
Warning: version conflict detected: org.clojure/clojure version changes from 1.7.0 to 1.8.0

richiardiandrea23:05:49

yeah maybe I can play with exclusions

micha23:05:05

yeah i would do like

micha23:05:22

(set-env! :exclusions '[org.clojure/clojure] ...

micha23:05:38

since you're going to have a direct clojure dependency anyway

micha23:05:56

actually a direct clojure dependency would fix the problem

richiardiandrea23:05:57

and it's weird because my boot env is 1.8.0, somebody is setting it to 1.7.0

micha23:05:07

do you have clojure in your :dependnecues?

richiardiandrea23:05:34

I also have others:

Warning: version conflict detected: adzerk/env version changes from 0.3.0 to 0.2.0
Warning: version conflict detected: org.clojure/tools.reader version changes from 0.10.0 to 1.0.0-beta1
Warning: version conflict detected: org.slf4j/slf4j-api version changes from 1.7.12 to 1.7.21
Warning: version conflict detected: adzerk/env version changes from 0.3.0 to 0.2.0
Warning: version conflict detected: org.clojure/tools.reader version changes from 0.10.0 to 1.0.0-beta1
Warning: version conflict detected: org.slf4j/slf4j-api version changes from 1.7.12 to 1.7.21

micha23:05:41

that's weird

richiardiandrea23:05:33

I will try to play with :exclusions

richiardiandrea23:05:59

btw all this is for a shining brand new boot template: https://github.com/Lambda-X/lambone

micha23:05:18

haha that's an awesome name

richiardiandrea23:05:02

a lot of your work I guess in this template

micha23:05:29

looks awesome

richiardiandrea23:05:58

I put all my boot knowledge in it, still things can be improved 😄

superstructor23:05:24

@richiardiandrea: nice! would you consider adding support for Dirac (jupl/boot-cljs-devtools vs cljs-repl), Garden (boot-garden vs sass) etc or is that out of scope / worthy of a fork ?

richiardiandrea23:05:07

@superstructor: sass is already there and I personally prefer it over garden...I am open to tooling (through options)

richiardiandrea23:05:05

The cljs Repl is already there with +frontend option and boot dev starts both repls in one JVM thanks to pods