thanks @flyboarder I can never seem to remember the diff between asset resource and source 😕

@lwhorton: it's documented on the wiki

@alandipert Why did you replace aot with a Java shim: https://github.com/adzerk-oss/boot-uberjar-example/commit/d0717cb1feeebcb4d2bffb535b4e5c50520ec2a8?

@kenny i wanted to not aot every class, just one that the jar needs as entrypoint

just aot-ing the entrypoint and then using require/resolve to load in the rest of the app would have worked also

I wrote a script with a few functions that we need available in our boot.builds, before set-env! is called. Currently we load it with load-file. Is it possible to package this as a library/task somehow?

@borkdude you can always call set-env! multiple times

like at one point i made a library with a function that generated the argument to set-env!

so yeah, i'd make it a library per usual, and then just bring it in via set-env!/require before the next time you do set-env stuff

ah

i believe the ability to do this subsumes e.g. maven archetype functionality

yes, that’s what I did too, a library to generate the argument for set-env

if you're making a jar or something in the consuming project, probably good to bring in your support lib w/ :scope test

yes

good point

alternatively you could make a pod at the top of yuor build.boot and load the library in there

then you're dep-conflict free

the library only uses native clojure