can't I call System/setProperty in a pod? -> clojure.lang.ExceptionInfo: java.lang.ClassNotFoundException: System.setProperty, compiling:(boot_dynamodb/pod.clj:51:5)

can you paste how you're calling it?

it's 2 args, both strings

probably a stupid error:

(defn- set-sqlite-native! [sqlite-native-dep]
  (let [sqlite-resolved-path ^String (pod/resolve-dependency-jar pod/env sqlite-native-dep)]
    (util/warn "Sqlite4java resolved to %s\n" sqlite-resolved-path)
    (System/setProperty "java.library.path" sqlite-resolved-path)))

Ah, I suspect the returned value of resolved-dependecy-jar is nil maybe

it might be a URL

oh

or a File or something

thanks let me see

Hi! I'm compiling a boot cheat sheet, and am wondering if there is something like Leins :injections in boot? Basically it evaluates a form into every ns, which is useful when having something that should only be run in development (as it is not included when making a jar/uberjar)

@codemartin there are similar things: 1) a file called `boot-shim.clj can inject anything, see at the bottom of https://github.com/boot-clj/boot/wiki/Configuring-Boot

2) there is -i option to boot directly for evaluating any form

3) there is a -e iirc to repl as well

In there you can call intern like for instance: https://gist.github.com/arichiardi/d2eda88d304b3a9002aac0e941d8cc05

@richiardiandrea thanks, looks great

I use ~/.boot/profile.boot and im.chit/lucid.core.inject for repl-enrichment

hey! i’m having an issue with namespaces being in :source-paths while running my test suite

not quite understanding why that’s an issue with the classpath, is boot not loaded into the pod running the tests?

the pod does not have access to the boot.core namespace

but boot.pod is available there

does that mean i can’t have tasks that compose boot.core tasks anywhere in source-paths?

or should i be resolving them in the tasks

yeah you want to do all of that in the core pod

the one the build.boot is evaluated in

you can't compile namespaces that refer boot.core in other pods, because that namespace won't be on the classpath

currently i have a separate build.clj file in a repo that has tasks that i use across a number of personal projects

and i’m using it as a submodule

instead of a checkout dep, because it changes frequenctly and i find it more convenient (maybe)

so at the top of built.boot i add that dir to :source-paths

which is a problem for other pods because i want to use boot.core stuff in that file

you shouldn't need to do anything with boot.core in other pods though

right that’s true, but it’s currently being loaded at the top of my build.boot, can i remove it from source-paths before other tasks?

you can do that, but it seems unnecessary

its presence on the classpath is a problem?

right

because it’s requiring boot.core

usually things can be on the classpath as long as you don't require them

yes but why is that namespace even being compiled in the pod?

good question

it should just be a random file on the classpath that you can safely ignore

it’s being required in build.boot

build.boot is not available in that pod

unless you explicitly do (load-file "build.boot") and evaluate that in the pod

ah i see

h/o let me investigate

it could be that the test machinery is finding the clj file on the classpath and looking in there for things to test

yea that’s possible

is there a good way to figure out exactly why a file was loaded?

the stack trace may have some useful info?

this problem would also be fixed if i packaged this is a jar instead of included it in :source-paths right?

sounds pretty likely that boot-test is finding the ns in source-paths and looking for tests

packing the tasks as a jar solves the issue

but seems like sidestepping the problem

@pleasetrythisathome you can exclude those namespaces from the tests

if you want to do it that way

tried adding it to (task options! test {:exclusions #{‘pleasetrythisathome.build}))

but still had the same issue

hmm that’s odd, it works if i set task options in built.boot but not if i do it inside the task

how does one disable boot's new version check thing?

or whatever is causing a stacktrace with " at Boot.download(Boot.java:173) " while s3 is down

--offline maybe?

it shouldn't check for a new version of boot

it only does that when it doesn't already have the version of boot you specify

if you do BOOT_VERSION=2.7.1 boot ... you should avoid the downloading

or whichever version of boot you have locally already

gah, I think this is just what I get for using docker, my testing docker container does the check, but I can't build a new docker container with everything updated to not do stuff with s3 because all the artifacts to build from are on s3

if folks need dynamodb local -> https://github.com/arichiardi/boot-dynamodb