This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (44)
- # adventofcode (2)
- # avi (1)
- # beginners (22)
- # boot (328)
- # cider (1)
- # cljs-dev (6)
- # cljsrn (29)
- # clojure (164)
- # clojure-chicago (1)
- # clojure-dev (7)
- # clojure-nl (5)
- # clojure-russia (73)
- # clojure-seattle (1)
- # clojure-turkiye (2)
- # clojured (1)
- # clojurescript (98)
- # core-async (6)
- # cursive (26)
- # datomic (9)
- # editors (5)
- # emacs (41)
- # events (3)
- # garden (2)
- # hoplon (125)
- # ldnclj (18)
- # om (178)
- # omnext (8)
- # onyx (5)
- # parinfer (1)
- # proton (5)
- # re-frame (20)
i corrupted one of the files in the maven repo by trying to deploy from my home connection which is super slow
Nice : Boot @ 36:26 : https://www.youtube.com/watch?v=50vU6rp2jyA (Interactive programming - Daniel Szmulewicz)
shouldnt each property be passed to something that checks it’s of the expected format?
like they are all strings really but this might also be good for the settings which are paths
@micha: now I know this is a task error but not sure if it means a bug in the option validation that was changed
@micha: im still having the issue where
.hl files in a checkout dep are not recompiled
is there a boot wish list somewhere? i’d really love to help working on clr support
the groundwork i think has been laid, becaue boot does work with dunaj, which is an alternative to clojure
yeah i can help with some of the c# interop but I think refactoring the codebase just to abstract the current logic would be the first step instead of trying to do both
mhm im trying to get through all the java, maybe making boot build with boot will be my next challenge, the multi thing looks promising with the target task now
so the classes that are loaded in boot already can't be compiled, because they're already loaded
one possible solution would be to have boot compile itself at runtime and cache the class files
that would be good also for binary compatibility, like you could compile for your version of the clr or jvm
that might give some optimization possibilities with newer versions of the platform maybe
Hi! I'm wondering if I am hitting a boot bug here. My project depends on
[circleci/clj-yaml "0.5.5"] and boot builds it into my uberjar - however, it also builds in a different clj-yaml project that my project depended on before. And that last one ends up being used.
As far as I'm aware none of the other dependencies provide the other
clj-yaml dependency. But I can't be certain. Is there a way to find out?
I just wiped the cache etc. and running
boot show (not finished) is downloading a
clj-yaml-0.4.0.jar, which I think is the thing I depended on before. So it must be used by one of the current dependencies.
you will want to add an
:exclusions [clj-yaml] to the dependency that is pulling in
Because they both use the same clojure namespace (`clj-yaml.core`) (one is a maintained fork of the other) but have incompatible function signatures.
Even org.clojure/clojure itself did depend on
circleci/clj-yaml in 1.6.0, but... yeah.
I guess so?
[:heavy_check_mark:] org.clojure/clojure ✘ 1.7.0-RC1 weasel :heavy_check_mark: 1.7.0 com.novemberain/pantomime com.stuartsierra/component org.clojure/clojure org.clojure/clojurescript
the lower level things are the dependencies in your build.boot that want to puill in different versions of the top level thing
but you can also see the checked one, which indicates the version that was actually chosen
and you can see it was chosen because you specified a version of clojure in your build.boot
I don't see a checked
circleci/clj-yaml though, so are all of these indirect/provided dependencies?
so cljs-yaml will show up in
boot show -d, but not in
boot show -p unless it's a contested version
:exclusions [org.clojure/clojure] to the deps under the second level heavy check mark
that's not a great example because you directly specified clojure in your build.boot deps
boot show -p shows that
ring-middleware-format uses the old
clj-yaml, hence the conflict.
Since I need that depedendency and the two
clj-yaml projects occupy the same namespace... is there a way to solve this?
I guess there is another way... roll my own fork as a different namespace in my project.
@micha: Maybe develop branch for next version and master for fixes to current version?
Personal branches are ok for rebasing, but if we start to merge PR's to a branch which is rebased, things start to break easily
Separate develop branch is only useful if we wanted to release bug fixes without releasing some new features
But that's not too useful, we can just release bug fixes with next feature release
yeah or make topic branches if we want to make a limited release to see if a feature is good or not
What does this mean? Implicit target dir is deprecated, please use the target task instead.
what will happen if you don't use the target task? Where do the compiled artefacts go?
yeah if you want the fileset to be dumped into a directory you'd want to use the target task
with boot 2.5.0, I am seeing this: Caused by: java.lang.ClassNotFoundException: clojure.core.reducers.CollFold
micha, how can I quickly revert to boot 2.4.2 on my production server. Emergency here.
@micha: OK, I'm back to safety on the production server. Now I can look at what happened with boot 2.5.0.
@danielsz: i get that error when i try to resolve CollFold without requiring cloujre.core.reducers
perhaps boot versions prior worked because we required reducers somewhere? and your code didn't have to
@alandipert: could be. But then it comes from a third party library. I don't use reducers.
@micha: @alandipert I think the problem was elsewhere. With boot 2.5.0, the build task produces project.jar while before it was producing an artefact named after the project pom. https://www.refheap.com/112766
The target task makes sense. I understand the motivation after having read the notes.
The pom task has been extended, but no API breakage. Is order of importance in the build pipeline (https://www.refheap.com/112766 ) that could explain my observation?
It looks like the pom's project name is not being carried over by the uber or jar task.
hey guys! Any ideas what can cause errors like this after upgrading to boot 2.5? http://paste.in.ua/1097/
@micha: This tripped me up: Jar task produces jar with default name (project.jar) when multiple poms are found in the jar and the --file option isn't given.
@micha: By specifying the filename with -file on the jar task I could get the expected pom project name back.
but that interferes with libraries that look for their own pom to know what version they are
Another thing I was wondering about: is there a use case for writing the fileset to multiple directories at once, since the :dir option is a set?
@micha: i might have to rewrite boot-runit against boot 2.5.0. In particular, the logic that was extracting information from the pom. It was selecting the first pom, since others were excluded. This logic is now broken if I understand correctly.
r will be the url here: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L737 and a string can't be merged with the repo-map
@micha: and @alandipert I could confirm that the change in jar exclusions breaks boot-runit. I can't just scan the fileset for a pom.xml and presume it belongs to the project. When building an uberjar, fileset is full of pom.xmls from dependencies.
I can add an option to boot-runit to provide the name of the uberjar, and get rid of the guessing.
but i don't know of any equivalent thing for applications, which is what your uberjar is