This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@crisptrutski: you did an awesome job with https://github.com/crisptrutski/boot-cljs-test and I really appreciated a lot your support in guiding me at using it in the proper way.
Recently boots jar
task started outputting my program into the file ./target/project.jar
instead of target/my-programs-name-0.1.5.jar
. Why is this, and how can it be controlled?
It also started putting a lot of stuff in ./target
- some things about cljs which I'm not even using.
It also complains I have no target
task. Fair enough - but how do you add one? Searched for target
in the wiki but found only
.
@codemartin about the target task not found, that task was introduced in boot 2.5.0, so it might be that one of your boot tasks assumes it exists but you are using an older version of boot so it's not available. Please check your boot version with boot -V
@nberger: probably the wiki should be updated as well https://github.com/boot-clj/boot/wiki/Target-Directory
@codebeige: https://github.com/boot-clj/boot/blob/master/CHANGES.md has the answers you seek. re: project.jar
, check out the file option of the jar
task - you can name the jar explicitly with it
@micha I just pushed the squashed commits to the junit PR. Also added two changes: it now saves the summary in the fileset metadata instead of creating a new file only for this purpose, and added a fix to avoid having the test counters mutiplied by two. More details are in the PR.
I also kept thinking about your notifications idea... It sounds great as a new notification mechanism that might allow having multiple notification targets (stdout, inotify, slack?, etc), I guess that's where we would get the most benefit out of it. But I don't feel it should be related to this PR.
It helps that now we are not introducing a new file for the test summary but just using the fileset metadata, so it's not that of a commitment that we wouldn't get rid of in the future (I understood from our conversation yesterday that you preferred to experiment with a new notification mechanism that would have other benefits instead of adding a new file to hold the summary and new tasks would start depending on that file, etc...)
Great! I've been waiting for junit output.
Then if someone would implement Cloverage for Boot
A question about the Boot file system abstraction… I had a need to download a specific set of dependencies (JARs) and then copy them into specific folders within the project. Those folders exist and already have a bunch of files in them which I don’t want touched. I also don’t want any other files copied into those folders but the specific dependencies I specify.
I tried to do it just via the Boot fs but couldn’t get it to exclude all the default dependencies in the main project...
when you say "within the project" you mean directories under source control? like actually in your project?
Well, they’re excluded folders, but they are actually in the project.
you probably want to use http://clojure.java.io/copy there
That’s what I ended up doing but I’d expected to be able to do it via just the Boot fs abstraction.
That they’re JARs is irrelevant really.
Yes, just too lazy to type that out
Even with the target
task?
and the sift
task to fileter out any files in the fileset you don't want to write to that directory
Maybe I’ll have another go at it next week. It just seemed harder than I expected.
I was hoping the Boot cp
function would do what I wanted but I couldn’t figure out how to get the TmpFile
for the destination so there’s something about the abstraction I’m not getting...
usually i'd make a Makefile or shell script if the project itself needs to be initialized
So suppose I have some folder X (in the project) that contains some files, and I want to do something (to tell Boot about some new input files), and I want those sync’d / copied into folder X — without deleting any other files from X and without adding anything except the specific new input files — is that doable with Boot primitives?
It seems like I could use target —no-clean
as long as I can limit the scope of the input files to just the new files...
OK. I tried setting source paths and resource paths to empty sets but the project values already took effect
Yay me! I found a bug!
OK, thank you. That confirms that what I was trying to do should have worked so my understanding of the fs abstraction isn’t as floored as I thought it was.
aw, you took @marty.penner 's 🍻 away
😛 typo
but now i feel bad
yay 🍺 for everyone 😄
@micha: https://github.com/flyboarder/boot/blob/master/boot/core/src/boot/task/built_in.clj#L93-L96
can you explain that part a bit?
that part adds the non-transitive depdencies of the checkout project to the consuming project
at the end it prefers your versions of those, if you have the same deps already specified in the consumer's build.boot
the resolve-nontransitive-dependencies function returns the dependency coordinates (like [foo/bar "1.2.3"]
), but also the path to the jar in local maven
so the checkout deps are never actually added as deps at all then? just to the fileset
which is why the ones in your deps are chosen over them?
yeah thats what I was doing, i just didnt see the deps get used at all which are being passed in other than as files
where not-checkout?
is a predicate that decides if a depenbdency is one of the checkout deps
oh that makes way more sense than the maps I was working with XD
mhm, ill give that a go
I notice that the boot.sh
downloadable from the site has changed. Is there a way to ask the shell file what version it is, independent of Boot itself?
(I already updated our copy for work but figured I’d ask, just for future reference)
@seancorfield: it doesn't expose its own version number
changes to boot.sh will be very rare, and the one you have should work for all future versions of boot
2.5.2 is in homebrew!
@micha: curious to see what you'll make for the API docs
@martinklepsch: 🍾 homebrew!
@micha: is there a way to suppress the warning for when checkout modifies the dependencies?
@flyboarder: which warning do you get?
Warning: version conflict detected: degree9/lounge.api version changes from 0.1.0 to 0.2.0-SNAPSHOT
the checkout task is checking to make sure it's not adding any deps that are already added
https://github.com/flyboarder/boot/blob/master/boot/core/src/boot/task/built_in.clj#L101-L103
deps is always empty
dependencies
is getting the vector passed to checkout
seems excessive
isnt it saying that i sucessfully added the new checkout dep?
oh just remove the old versions
ah ok i can fix that
right as files in the fileset
ok makes sense
so you were right i did want (vec deps)
in that case
yeah that works
@micha nice! 🥥