After updating boot I get the following exception: Multiple jar entries match : .*/pom.xml Anybody has an idea what could cause that exception.

@msattel: can you paste a full stacktrace please?

you shouldn't be seeing that

you can use the -vv option to boot itself to get full stacktraces

with no ansi colors

Released java.util.concurrent.Semaphore@661972b0[Permits = 1]... Installing project.jar... clojure.lang.ExceptionInfo: java.lang.Exception: Multiple jar entries match: .*/pom.xml {:file "/tmp/boot.user209501624813010180.clj", :line 49} at clojure.core$ex_info.invoke(core.clj:4593) at boot.main$main$fn_1272.invoke(main.clj:199) at boot.main$_main.invoke(main.clj:192) at clojure.lang.Var.invoke(Var.java:394) at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:159) at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:150) at boot.App.runBoot(App.java:390) at boot.App.main(App.java:467) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at boot.Loader.main(Loader.java:253) Caused by: java.util.concurrent.ExecutionException: java.lang.Exception: Multiple jar entries match: .*/pom.xml at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at clojure.core$deref_future.invoke(core.clj:2186) at clojure.core$future_call$reify__6736.deref(core.clj:6683) at clojure.core$deref.invoke(core.clj:2206) at boot.core$boot.doInvoke(core.clj:801) at clojure.lang.RestFn.invoke(RestFn.java:408) at boot.user$eval489.invoke(boot.user209501624813010180.clj:56) at clojure.lang.Compiler.eval(Compiler.java:6782) at clojure.lang.Compiler.load(Compiler.java:7227) at clojure.lang.Compiler.loadFile(Compiler.java:7165) at clojure.lang.RT$3.invoke(RT.java:319) at boot.main$main$fn_1272.invoke(main.clj:192) ... 11 more Caused by: java.lang.Exception: Multiple jar entries match: .*/pom.xml at boot.pod$find_in_jarfile.invoke(pod.clj:120) at boot.pod$pom_xml.invoke(pod.clj:190) at boot.aether$install.invoke(aether.clj:178) at clojure.lang.Var.invoke(Var.java:388) at clojure.lang.AFn.applyToHelper(AFn.java:160) at clojure.lang.Var.applyTo(Var.java:700) at clojure.core$apply.invoke(core.clj:630) at boot.pod$eval_fn_call.invoke(pod.clj:294) at boot.pod$call_in_STAR_.invoke(pod.clj:315) at clojure.lang.Var.invoke(Var.java:379) at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:109) at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93) at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28) at boot.pod$call_in_STAR_.invoke(pod.clj:318) at boot.task.built_in$fn__2203$fn__2204$fn__2210$fn__2211.invoke(built_in.clj:725) at boot.task.built_in$fn__2078$fn__2079$fn__2085$fn__2086.invoke(built_in.clj:618) at boot.task.built_in$fn__1903$fn__1904$fn__1914$fn__1915.invoke(built_in.clj:495) at boot.task.built_in$fn__1761$fn__1762$fn__1771$fn__1772.invoke(built_in.clj:342) at boot.task.built_in$fn__1594$fn__1595$fn__1601$fn__1602.invoke(built_in.clj:221) at boot.task.built_in$fn__1997$fn__1998$fn__2006$fn__2007.invoke(built_in.clj:555) at boot.core$run_tasks.invoke(core.clj:794) at boot.core$boot$fn__904.invoke(core.clj:804) at clojure.core$binding_conveyor_fn$fn__4444.invoke(core.clj:1916) at clojure.lang.AFn.call(AFn.java:18) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)

ah you're installing a jar that contains more than one pom.xml file

boot looks in the jar to find the pom.xml

the install task takes a --pom option

you can provide the path to the pom in the jar

the resource path

usually when you deploy a jar you won't want to have multiple pom.xmls in there

so isn't that a problem with my pom task???

and thanks for your advice, I will test it

are you making an uberjar?

maybe if you paste your build.boot

something will stand out

if you could paste it into a snippet in slack it will be easier to read

(task-options! pom { :project 'wareblog :version version } target { :dir '#{"target"} :no-clean false } aot {:namespace '#{wareblog.embedded}} jar { :manifest {"description" "test clojure and boot"} :main 'wareblog.embedded }) (deftask build "Building the project" [] (comp (aot) (target) (pom) (uber) (jar) (install)))

and this is my env:

(set-env! :source-paths #{"src/main/clj","src/test/clj","src/main/resources"} :resource-paths #{"src/main/resources","src/test/resources"} :dependencies '[ [adzerk/boot-test "1.0.4"] [adzerk/boot-cljs "0.0-2814-4"] [org.clojure/clojure "1.7.0-RC1"] [environ "1.0.0"] [ring/ring-core "1.3.2"] [http-kit "2.1.18"] [bidi "1.18.11"] [liberator "0.12.2"] [com.taoensso/timbre "3.4.0"];logging [selmer "0.8.2"];templates [com.stuartsierra/component "0.2.3"] ])

so if you do boot pom show -f do you see more than one pom.xml file?

oh i see

you are making an uberjar

so you will need to specify the path to your pom in the task-options

I see one pom.xml file

(task-options!
  install {:pom "META-INF/maven.wareblog/pom.xml"})

or something like that

but installing/deploying uberjars is pretty unusual

why are you making an uberjar there?

if you're using maven you can just declare dependencies, no?

deploying an uberjar will defeat the whole dependency system

and you will end up with conflicts

that you can't see or debug

uberjars are for applications, which you don't need to install in maven

you just run them

but if you really do want to deploy an uberjar to a maven repo you can just specify which pom you want to install/deploy with

thanks a lot for that explanation, I will test

👍

I just thought it might be a good idea to install a uberjar, because I wanted to package the application in a single jar file. What is the best way to package an app with all its dependencies in your opinion?

uberjar is perfect for that

but why do you want to install it in you maven repository though?

i.e., the install task

you just want a jar that you can run via java -jar ... right?

exactly

yeah you can just remove the install task from your build there

and put the target task after the jar task so the jar file is written to the target dir

the output of one task becomes the input to the next

so you want to feed the jar file produced by the jar task to the target task

if that makes sense

if you want just the jar file in the target dir you can add this in between the jar and target tasks:

(comp
  ...
  (jar)
  (sift :include #{#"\.jar$"})
  (target))

where ... is your other tasks you already have there

then you'll have a target directory with just the single jar in it

very nice, actually where is that documented?

you can do boot -h to see a list of all tasks

or in the repl (boot (help))

and for documentation for a specific task you can do

boot sift --help for example

or in the repl (doc sift)

ok thank you

also there are API docs on github

https://github.com/boot-clj/boot/blob/master/doc/boot.task.built-in.md

for example

and final question

Implicit target dir is deprecated, please use the target task instead. Set BOOT_EMIT_TARGET=no to disable implicit target dir.

just wondering why it tells me to use the taget task, because actually I am using it

you can set that in your shell environment like export BOOT_EMIT_TARGET=no

or in your ~/.boo/boot.properties file

this is because boot didn't have a target task until recently

the default behavior was to write to the target directory automatically

👍

but we found that this wasn't so useful

awesome, thank you for the help

because most of the time you're either working in the classpath, like when you're testing

or you want to emit the target stuff to somewhere in the cloud

emitting files to the local filesystem for each iteration was a waste

so the BOOT_EMIT_TARGET env var is for compatibility

by default boot will continue doing what it did before

it's a feature flag basically

I like having an explicit target directory, as in most cases I prefer explicit definition over implicit magic.

Nice work, I am really excited to find out more about boot, have to leave now, thank you for your support.

have fun! come back if you run into issues

^ this is so cool!

@richiardiandrea: what? zerobitcoin?

Yep

Yep

By the way I didn't forget your confetti but the boot porting of my project is going to happen soon 😉

@richiardiandrea: no worries

Actually I thought zerobitcoin was new bitcoins project, but well, dunno

is anyone else having issues with boot 2.6-SNAPSHOT not finding some project files?

@flyboarder: what kind of issues?

just that some files in my src/ folder are not picked up, it worked fine with 2.5.5

can you make an example?

possibly, im not sure what the difference between the files that are picked up and the ones which are not

ill see if i can reproduce on a smaller repo

what do you mean by "picked up"

like they don't ever make it into the fileset?

yeah

do youhave a .bootignore file?

nope

ok just checking lol

is your monitor plugged in?

haha j/k

hahah 😛 yeah it’s weird

i will deploy a new snapshot, it's possible that one is not 100% up to date

@micha: i figured it out, once it hits a folder in src/ in this case src/state no letters after s in my src/ folder is seen

ok new snapshot available

same issue

@micha: looks like it isnt recursively going through src/

hm

im working on a demo

@micha: https://github.com/flyboarder/filesetbug boot show -f

@micha: I pushed a change and removed all the useless code

@juhoteperi: ^ now people cant easily copy the clojars coordinates anymore

I know... but I hate that each time I do release I forget to run build-jar and then I can't do a release because it updates the readme just before push and then push fails because repo is not clean

It's not possible to use javascript links in github, but it would probably be possible to link to a page which would copy the coordinate upon page load

Guys just a theoretical question, why do I need :scope "test" when declaring a dependency in boot? Is it the same meaning as in maven?

@richiardiandrea: yes, it prevents that dependency from being included as a transitive dependency of a project that depends on your project

Also prevents the dependency being included in uberjar

thanks!

it'll stil be in the generated pom.xml of course

hey micha, alandipert, are you guys still interested in using something like boot-sassc with JRuby + Sass (for Compass) or did you guys end up rolling your own solution? https://github.com/mathias/boot-sassc/issues/12#issuecomment-132851213

in tenzing I see that it requires for instance boot-reload at the beginning of build.boot but can't I do it just in the development task (that is where I need it) ?

@mathiasx: we're using boot-sassc currently with libsass

@richiardiandrea: yes you can

oh ok

@micha: OK to PM so I don’t clutter up the channel? lol

sure!

@richiardiandrea: the benefit of adding the test dependency is that you can resolve all your deps at once

which reduces the possiblity of dependency conflicts

like maven was really not designed for dynamically adding dependencies

because of the way it internally resolves dependency conflicts

@micha thanks, I feel that after setting the options in development I could call the big require, or maybe split set-dev! where I just set deps and development where I actually require and do stuff...

@micha: great thanks for expanding on this

like if the dependency you add dynamically has transitive dependencies that conflict with ones already loaded

if you did them all at once aether would resolve those dependencies differently

because it can see the whole graph

ah wow did not know that

make sense though

Also, without top level require you can't refer to required vars directly but would need to use resolve to resolve symbols to vars in runtime

oh

so I can't do

(deftask run []
  (require
   '[adzerk.boot-cljs      :refer [cljs]]
   '[adzerk.boot-cljs-repl :refer [cljs-repl start-repl]]
   '[adzerk.boot-reload    :refer [reload]]
   '[pandeiro.boot-http    :refer [serve]]
   '[crisptrutski.boot-cljs-test :refer [test-cljs]])
  (comp (serve)
        (watch)
        (cljs-repl)
        (reload)
        (build)))

(comp ((resolve 'pandeiro.boot-http/serve)) (watch) ((resolve 'adzerk.boot-cljs.repl/cljs-repl)) ... would work

Clojure will read the whole file first and try to resolve all symbols to vars, without top-level require reader can't resolve symbols to vars.

understand, but I guess I can stick with the top level require, as the performance hit is minimal

boot is faster than lein in any case on my machine

you can also wrap in eval instead of using resolve i think

(deftask foo []
  (require '[sadf.qwer :refer [foop]])
  (eval '(foop 100)))

i think that would work

less verbose, I can try that out

where can I find boot.build example files?

clojure.lang.ExceptionInfo: Unable to resolve symbol: cljs in this context

I want tasks to: build jar file, run tests whenever a file is saved, run repl, run app

@esnunes: the README for boot on github is a start

I read the whole README file, it tells me how boot works and how to create tasks. I've just realized there is "documentation" link right on the top, which points out to the wiki

thanks @micha

(deftask build []
  (require
   '[adzerk.boot-cljs      :refer [cljs]])
  (comp (speak)
                 (resolve 'adzerk.boot-cljs/cljs)))

https://github.com/search?utf8=%E2%9C%93&q=build.boot+extension%3Aboot&type=Code&ref=advsearch&l=&l=

plenty of examples there

just toying around

@richiardiandrea: Try wrapping (resolve...) in paretheses

ah! better

right because it returns a function 😄

@esnunes: also the boot wiki and api docs

@micha I was avoiding search for examples right on google or github due to the fact that as boot is a very active project I might end up finding outdated examples, I will focus on wiki and api docs first , thanks

(deftask build []
  (require
   '[adzerk.boot-cljs      :refer [cljs]])
  (comp (speak)
        ((eval 'adzerk.boot-cljs/cljs))
        ))

@esnunes: we haven't made any breaking changes since 2.0.0, which was december 2014 i think

but the tasks may have changed since then, of course

nice, I'm totally new to boot, actually new to clojure too

@micha: I guess you could even think about wrapping this require plus ((resolve ...)) in some sort of macro that does expose the symbol in the body...jst throwing ideas around 😉

yeah you could make a macro that evals each expression separately at runtime

clojure does that itself for top level forms

that's why you can do this in your build.boot:

(require '[foo.bar :refer [baz]])

(baz 100)

because the clojure compiler will compile and eval each top level form separately

but each top level form is compiled as a unit

so inside of there you can't introduce new bindings except with let etc

i mean you can, but the compiler won't see them

because the require that's inside the top level form won't be evaluated until the entire top level form is compiled

@micha it feels cleaner (to me at least) to have a require in the task that needs it, that is reason of my idea...but I can live with the way it is now :)

yeah you can do that for tasks especially

since the tasks don't have any transitive dependencies

so there isn't any chance of the dependency problems i described before