This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
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
@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...)
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?
That’s what I ended up doing but I’d expected to be able to do it via just the Boot fs abstraction.
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
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.
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
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
not-checkout? is a predicate that decides if a depenbdency is one of the checkout deps
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)
changes to boot.sh will be very rare, and the one you have should work for all future versions of boot
@micha: is there a way to suppress the warning for when checkout modifies the dependencies?
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