#hoplon

Good morning! I'm currently evaluating clojurescript for front-end stuff (yay CSP) and having an awful time getting things rolling. Right now I'm having trouble getting boot-reload to work (I develop on a VM locally via ssh and sftp, breaking the 'localhost' default)

This pull request looks promising-- what's the clojurescript process to nab the commit, test it, and then contribute back when it's cleaned up?

And, also, where the heck do I set default values for deftask args?

Just fork, edit and PR repo on github

And what kind of default values do you mean? If you mean something you would set on the projects build.boot, use task-options!

If you mean default for task implementation, just use `or` in the task where the value is used

Deraen: Right, fork edit etc is standard-- I'm actually confused about "how do I use this while editing it"

Kavec: "boot build-jar" installs the package to local maven repository, so when other projects use boot-reload the locally installed version will be used

And "boot watch build-jar" will install the package to local repo whenever a file is changed

Alright, thanks! As soon as I verify that I didn't screw something up with websockets, I'll hunt down the understanding I need for those instructions (no experience with java environments, little interest in experiencing them either)

that's all I need to answer those questions, though, so thanks again :)

Deraen: You have a new pull request for boot-reload, let me know if it needs any changes to be accepted :)

So, next problem-- when I save a change to an html file, boot-reload is properly triggered, but for whatever reason a blank html file has been copied over to target/ and is served instead of the actual html. Where do I need to head to fix that?

Kavec: i recommend not serving from the target/, serve resources from classpath instead

michaniskin__: I don't know java; how do I reason about what the classpath is?

it sounds like the easier route

can you paste your build.boot file?

the classpath is where java looks for resources it needs to compute

it's an abstraction one level above filesystems basically

the classpath is sort of like an overlay filesystem, where multiple sources are all accessible via a common interface

so resources in jar files, in the filesystem, or whatever are all accessed the same way

it's pretty useful

I'm thinking if it would be best to remove option to serve stuff from filesystem in boot-http :/

yeah

that sounds like a pain in the ass

(I'm coming from golang)

I'd rather not paste my exact build.boot-- it's based on https://github.com/adzerk-oss/boot-cljs-example...

how does golang handle packages with resources in them?

what do you mean by a resource?

like in java i have a jar file that contains some image, cats.gif

Oh

some other code in a different package is looking for cats.gif

that's... not really a thing

You can use go.rice to bake resources into a binary

but by convention, a package is a directory on disk underneath $GOPATH

it's really a pain in the ass then, i imagine, when you need it

so if you really need to look into a .gif some package has, you already know where it is

because you imported that package anyway

then you will want to keep those compressed

because you might only need one thing

so they will add that too

like jar files

and you will eventually have a classpath in golang

I don't understand the rationale for including resources in.. what's essentially a library

from my perspective

instead of distributing them on their own

because they need to be versioned

with the package they pertain to

oh, yeah. That's... golang's solution for versioning is a mess

are you using the boot-http task for serving your application?

as in, there isn't a canonical way to version or vendor

I am

are you giving it options?

it's exactly as in the boot-cljs-example build.boot

I'm thinking it really great way to solve static assets by thinking them as libraries

just remove the `:dir "target"` part

golang also assumes everything is distributed as source-- you have to jump through hoops to hand out binaries

Deraen: cljsjs has been working well for me with sifting things out of the jar, the static resources like css

it'd be nice to have a better solution for distributing library binaries

binary applications can have their assets baked-in

Kavec: that's a good example, we have this cljsjs thing, where we package up various js libraries as jar files in maven

so you might have a package for jquery-ui for example

we can now have jquery-ui participate in the dependency graph for the rest of our application as a first class member

In Java jars support both, distributing the source and distributing the binaries

i.e. we never have multiple versions of it pulled in

and this package comes with css that needs to be versioned with the specific version of the jquery-ui javascirpt

this is what allows the abstraction, you don't need to handle transitive dependencies

reading the source, it looks like the golang -> js compiler builds library bindings to jquery and relies on the user to import jquery themselves

yeah so now what happens if 5 packages depend on jquery

and on other things

you have to know all about the internals of all of them

and all of their transitive dependencies

like maybe i just wnat to use some library that depends on a library that depends on jquery

it's unacceptable to need to manage all that manually

I'd actually prefer that; I'm trying out boot with cljs because from my perspective leiningen generates a magic node.js-a-like environment when creating a new project

well you don't need to use maven :)

just don't add :dependnecies

you can download jars manually and add them via command line options

at which point I have to learn java :)

or even just unzip everything into :source-paths