OK, the first problem is your boot.new.readux_starter namespace — should be readux-starter (`_ in filename, -` in namespace).

^ @pseud

That gets you to this exception

Generating a new project called pseudapp2 based on the 'readux-starter' template.
Template resource 'boot/new/readux_starter/README.md' not found.

And that’s because you have - in the folder name instead of _

Once both of those things are fixed, it generates correctly.

https://github.com/seancorfield/boot-new/issues/26 <— I’ll make error handling better around that

does anyone know a trick how i can publish a local package to my local .m2 repository and fetch it within another boot project?

this to double check if it works fine before publishing it to the wild

@pseud with the latest boot-new (0.4.7) you’ll now get this

boot -d seancorfield/boot-new new -t readux-starter -n pseudapp2 -V 0.1.2-SNAPSHOT
Retrieving boot-new-0.4.7.pom from 
Retrieving boot-new-0.4.7.jar from  (44k)
Retrieving maven-metadata.xml from  (1k)
Retrieving boot-template-0.1.2-20160913.205445-1.pom from 
Retrieving boot-template-0.1.2-20160913.205445-1.jar from  (8k)
Found template readux-starter but could not resolve boot.new.readux-starter/readux-starter within it.
clojure.lang.ExceptionInfo: 1
    data: {:file
           "/var/folders/p1/30gnjddx6p193frh670pl8nh0000gn/T/boot.user7778462556735229335.clj",
           :line 17}
             boot.App$Exit: 1
boot.new-helpers/resolve-template/invokeStatic  new_helpers.clj:   78

@michael.heuberger a task like this should work

(deftask build []
  (comp (pom) (jar) (install)))

Then boot build will make a JAR and put it in your local ~/.m2/repository per the task-options! you’ve set for pom and jar.

(that was how I debugged and resolved @pseud’s problem above btw)

@seancorfield thanks, i did that. but then, the other project can’t find it when i declare it as a dependency there

how do you declare a local dependency in build.boot?

so that it will look up in .m2/repository and not on i.E. clojars etc

It just does it automatically.

It’s just a regular dependency. Because you have it cached locally, boot (or rather aether) won’t look on Clojars etc.

The only caveat is snapshots since it will check each day for a new version (I believe).

@seancorfield well, it doesnt. and i see this red error clojure.lang.ExceptionInfo: Could not find artifact …

it always looks up in clojars, not locally

are you sure you have the correct options for pom and jar when you install it locally?

i can find it fine in .m2/repository ...

it’s just the other project that can’t find it

(I do this all the time, BTW, and it works just fine — I did it just 30 mins ago to test and debug the readux-starter template)

I’d have to see your build.boot file for the project you’re building & installing locally and the dependency in the other project’s build.boot file — and perhaps details of the tree / files in ~/.m2/repository to be able to debug this any further for you.

probably there are other external factors that can mess with this

@seancorfield Thanks a lot for looking at this - hopefully it’s not terrible form to leave a question overnight as I did 🙂 I thought some of it was due to the dash/underscore debacle but it didn’t seem to resolve things for me yesterday. I’ll look into your instructions properly once I’m off work. It’s much appreciated 🙂

NP. The error message wasn't great... It should be better now 🙂

@michael.heuberger wrt to finding local jars. boot-new looks in your local repo’s first, then at clojars, then a whole list of places. I found that out by 1. bumping the version of my library to something more than what was available at clojars 2. trying to fetch it in another project and failing 3. installing it locally (`(comp (pom) (jar) (install))`) 4. trying to fetch the project again and succeeding. Now, keep in mind that boot will ignore your bumped version if it’s a snapshot. In case of boot-new I could circumvent that by passsing -S (look for a snapshot) or explicitly specifying the desired version with -V

☝️:skin-tone-2: Thank you for that @pseud

You are very welcome 🙂

@martinklepsch is there an example project for https://github.com/martinklepsch/s3-beam? i would like to have a feel for it 1st and inspect the various bits of data passing thru it, then i would probably make javelin/castra version of it

@onetom no example except for the stuff in the readme

java.io.FileNotFoundException: Could not locate boot/core__init.class or boot/core.clj on classpath., compiling:(cloudformation/boot_cloudformation.clj:1:1)

@mitchelkuijpers That looks like boot-cloudformation (what is that?) is to blame? I'd guess that boot-test is loading up that file to check if there are tests in it or something like that

Yeah that seems to be the problem

boot-cloudformation are some of our internal tasks we use to run cloudformation commands

Now i am trying to exclude it with sift

sifting it does not seem to work hmm

@mitchelkuijpers boot.core isn't available by default inside pods

@alandipert Yeah i have just added it as a dependency, took a while to realize that

(and test task runs tests inside pod)

thnx

np. be also advised that depending on what you're doing with boot.core in a pod, it might not work

but if it's fixed then you don't need to worry about it 😄

We are not really doing anything with these tasks in our tests. boot-test is just very commited to compiling the thing 😛

@alandipert what's the best way to ignore a namespace when using boot-test, out of interest?

it takes a :namespaces key for the namespaces to run, is that what you mean?

oh, and also :exclusions to do the inverse

@alandipert So instead of :exclusions, it would work to do :exclusions '[boot-cloudformation] (or however the argument looks to boot-test)?

i think so. i tend personally to explicitly give it my test namespaces to load

i.e. using :namespaces instead

@alandipert Makes sense 🙂

there's also the :filters option which works like (test :filters '[(re-matches #".*test.*" (name %))])

which in retrospect is too weird to have included

That makes sense I think. A way to test all test namespaces

yeah - all the ones with test in the name

How exactly does Boot mess with the classpath upon modifying and committing the fileset? I have a piece of code which I want to access both static files and a file generated by a boot task before running the main program. My problem: when I do (io/resource "data") at compile time, I can access the static files, but not the generated one. When I do (io/resource "data") at run time on each call, I can only access the generated file, but not the static ones.

@zilti sounds like your static files are in :source-paths? that means they don't have "output role" and woulndn't make it into a jar

@alandipert well, the folder they're in is in both :source-paths and :resource-paths. So, that's the problem?

could be, try putting everything in resource-paths

source-paths are for files that are to be "consumed" during the build, like .java

or .clj if you're AOT-ing

@alandipert Hmm, I've put everything in :resource-paths only now, still the same problem...

Does the task order matter at this point? I basically have (comp (run-application) (watch) (gen-file)) since I want the task to re-generate the file upon change.

oh hm - so at compile time, you're not accessing the files using the fileset api?

also what is the task that does the transform?

I access the files after the transform happened for the first time, using the normal http://clojure.java.io API, and the transform simply evaluates a clj file and stores the result into a file in the fileset (first in a tmp-dir, then committing it, exactly the way it is described in the fileset tutorial)

what is the differenc between compile time and run time in your case? boot entrypoint vs. java -jar or servlet?

No, I always run the application via boot. The difference is that in the "compile-time scenario" the (io/resource "data") is in a "let" expression around the function, and in the "run time scenario" it is inside that same function.

the output of yuor task needs to be on the classpath to be useful? or if you had a File object, would it be useful?

I don't want to push File objects around the whole application whenever the input changes, so, I'd prefer not to

so i think the underlying complication here is that your compile and run times share a classpath

i would tackle this by running the app in a pod

so working back from the pod, a task is responsible for creating/starting the pod with the :directories argument, which is a list of dirs you can tell pods to put on their classpath

i would use the target task to sync the FS to a temp dir, and then use that dir as the :directories for the app pod

at this point, your app sees only and exactly what's in the fileset at the end of your build process

this would also allow you to have different sets of dependencies for build vs run

i haven't done anything exactly like this so its just my intuition, there might be blockers i can't think of

circling back to your original problem, i think the issue is that all the files you need at runtime are in the fileset, but they're not necessarily on the classpath

https://github.com/alandipert/boot-trinkets/blob/master/src/alandipert/boot_trinkets.clj has an example of running pipeline-generated code in a pod

i use that to dev java in a watch/reload fashion

@zilti did you say that :source-paths and :resource-paths share a directory?

if there is any overlap between them then undefined behavior will result

there should be an exception thrown

eg. :source-paths #{"src"} :resource-paths #{"src/foo"} is a no-go

@micha I removed it, but it didn't make a difference 🙂

@alandipert Thanks, I will look at that!

I solved it by adding "(add-resource (io/file "resources"))" now. 🙂

@zilti is "resources" not in your :resource-paths?

@micha yes, it is. That's why I am so confused about all this in the first place...

yes that isn't going to work, something is wrong

Well, it does work now, so there's that

usually you use add-resource to add temp dirs

well it may work at the moment, but it's definitely going to confuse things

do you have tasks that are writing to "resources" dir?

@micha: And that's exactly what I did. I added the path "resources" to the fileset

yes, I do have one writing there

ah that's the problem

Or, not directly there, but into the fileset's equivalent location

Anyone have any references/examples of how to convert a lein template that uses profile-hints to boot? eg lein new duct [app_name] +hint1 +hint2 +hint3? I’d like to submit a PR to duct for using boot but I haven’t seen examples of this functionality.

what are profile hints?

@zilti so you want to undo what that task did?

like the task overwrites something in resources, and you want to undo that?

@micha The way I do it now is: 1. add "resources" to the fileset 2. launch the application 3. the task writing a file into "resources" (not overwriting) is run upon changes

@micha project templates with conditional code… eg. {{#cljs?}}[org.clojure/clojurescript "1.8.51"]{{/cljs?}} see https://github.com/duct-framework/duct/blob/master/lein-template/resources/leiningen/new/duct/base/project.clj

@zilti i work this way all the time wihtout needing to add anything via add-resources

like for example starting a pipeline with the cljs compiler and a jetty local dev server

you can try this yourself

the cljs task will write new files to the fileset

like boot watch cljs serve for instance

when you change a source file it'll recompile, which adds files to the fileset

then the server can see them

on the classpath

how is that different from what you're doing?

@micha Hmm, my ordering is different: I basically have "boot add-resources-and-launch-application watch writing-task

you should put your application at the end

then it will not start until the things it needs have been created

but you want to start it in a background thread of course

so it doesn't block the pipeline

and in a delay so it doesn't start every time the watch fires

A delay?

`
(deftask doit
  []
  (let [start (delay (future (start my server)))
        stop  #(stop my server)]
    (cleanup (stop))
    (with-pass-thru fileset @start)))

the delay makes sure the server is only started once

and the cleanup part makes sure it's stopped

(when the pipeline ends)

@micha please disregard my previous query, I was not thinking about this in the right way. I can just generate the boot file!

@dadair whew! excellent!

i saw reader literals and started backing away slowly 🙂

lol joking of course

🙂

@micha hmm your solution brings with it that I again don't get the static files ^^

@zilti static files?

@micha the files that already are in the folder and aren't generated by the task

so if you add show -f right before your server task in the pipeline, do you see those files?

perhaps you have a task that is removing those files frrom the fileset

or they're not in the fileset in the first place (eg. not in :resource-paths)

Yes, with "show -f" I see them.

hm ok

so you can see them with show -f but your task doesn't see them on the classpath, is that the situation?

and the files are in a directory that is in :resource-paths?

if you can see them with show -f then they're in the fileset

but if you have them in for instance :asset-paths they won't be on the class path

Yes and yes. Actually, the application does see the static files, but not the dynamic ones, when I do (io/resource "data") (data is a directory inside "resources") as a top-level in my .clj, but the inverse is true - sees the dynamic file, but not the static ones - when I do (io/resource "data") inside a function.

there are no directories in the fileset

only files

like git

Except when I do a (add resource (io/file "resources") inside my build.boot

Then, everything works fine.

there is no resource associated with a folder in the fileset, or the classpath, so i'm not sure what (io/resource "data") would mean

the fileset is a set of files with associated paths, basically a key value store

Yes. But inside my application I access them with http://clojure.java.io/resource.

maybe you are not calling commit! somewhere

so the fileset doesn't actually reflect the actual classpath

or vice versa

Oh I do call commit! whereever it is necessary 🙂

hmm

i don't understand what is different about what you're doing from what a typical cljs build does

it's very common to be creating new files in the fileset alongside existing files

and i have never seen files become invisible from the classpath before

i mean if the files are in the internal boot directories then they will be on the classpath

Is there an ETA on 2.7.0?

noob question: why does target/ contain tons of source files? Should it?

@arohner it will contain any files in the fileset that have the "output" role

that is things from :resource-paths or added via add-resource to the fileset

if you don't want to have certain files in there you can use the sift task to filter them out

it looks like it also contains unzipped dependency sources files

is this an uber jar?

it must be i guess if it contains unzipped dependencies

and yes, that's supposed to be like that, as the target dir will contain all the files in the fileset with the "output" role, which is the same as the files that would be included in a jar if you were to make one of those

yeah, it is an uberjar

yeah when you use the uber task you unzip all those dependencies into the fileset

so unless you remove them they'll be in there when you call the target task

and it will write them out

tasks are not coupled, so the target task just does one thing and one thing only: it writes out files that are in the fileset to some directory

it knows nothing about uberjars or anything else

likewise, the jar task doesn't know anything about uberjars either

you can make an uberjar by chaining the uber task before the jar task

the jar task simply creates a jar file that contains the files in the fileset

and the uber task only knows about unzipping dependencies and adding them to the fileset

so to make an uberjar you compose uber and jar tasks

if you want a pom.xml in your jar for whatever reason you compose with the pom task, that only knows about creating pom.xml files and adding them to the fileset

and at the end, the target task only knows to take all the files in the fileset and write them to a directory

so if you do boot uber target then it will write out all the files

having problems with data_readers

doesn’t Boot merge several data_readers.clj?

it’s either not merging them or not loading any at all

even after adding (load-data-readers!) to my build.boot

help?

try (boot.pod/resources "data_readers.clj")

@micha turned out to be PEBCAK

moved (load-data-readers!) before requires

haha ok

lol what's a PEBCAK ah ah sounds some funny internet acronym 😄

@richiardiandrea "Problem Exists Between Chair And Keyboard"

aaaaaaaaaa nice

always nice to learn new cool ways of blaming yourself 😄