

Clojure build tool Boot 2.0 RC1 out now - wooby
http://adzerk.com/blog/2014/12/boot2-rc1-out/

======
onetom
I was using `grunt` and `gulp` to build Node.js and AngularJS projects but I
have to tell even boot 1.0 felt like a great step forward compared to them,
despite of the abysmal startup times.

It allowed us to just jump into Clojure development from one day to the other
while understanding what is the build system doing. I can't tell the same
about the prepackaged grunt and gulp files which come with certain key-turn
projects.

~~~
lynndylanhurley
I've worked extensively with both grunt and gulp for the past couple of years
(I've even written gulp plugins![1][2]), and I'm still shocked at how bad the
tooling is compared to ruby (rails asset pipeline / sprockets) and clojure
(leiningen, chestnut, etc.).

For example, here is a simple gulpfile for a livereload environment that
compiles sass and coffeescript [3]. It's over 500 lines long, and it requires
extensive knowledge of at least 20 plugins. And half of those plugins are
there to address the shortcomings of other plugins, or of gulp itself [4].

But really the worst part is that every time some dependency of a dependency
pushes a point release, it breaks the entire build. My team has resorted to
passing around a stable `node_modules` dropbox folder. I'm literally terrified
to run npm update!

Anyway boot looks cool, I can't wait to try it out :)

[1] [https://github.com/lynndylanhurley/gulp-rev-replace-
stream](https://github.com/lynndylanhurley/gulp-rev-replace-stream)

[2] [https://github.com/lynndylanhurley/generator-gulp-of-
drano](https://github.com/lynndylanhurley/generator-gulp-of-drano)

[3] [https://github.com/lynndylanhurley/generator-gulp-of-
drano/b...](https://github.com/lynndylanhurley/generator-gulp-of-
drano/blob/master/app/templates/_gulpfile.coffee)

[4] [https://www.npmjs.com/package/gulp-
buffer](https://www.npmjs.com/package/gulp-buffer)

~~~
wooby
Wow, that all sounds like an absolute nightmare!

Have you taken a look at broccoli[1]? We ran across it after going the Fileset
route, but were refreshed to see that it also does a kind of Fileset thing
(they call them "trees")[2]. I don't know much more about it other than that
it's what's underneath ember-cli, and the Ember people do a lot of good work
in tools realm. Anyway, it could be a way for you to realize some of the
niceties of the boot approach over in JS-land.

1\.
[https://github.com/broccolijs/broccoli](https://github.com/broccolijs/broccoli)

2\. [http://www.solitr.com/blog/2014/02/broccoli-first-
release/](http://www.solitr.com/blog/2014/02/broccoli-first-release/)

------
dustingetz
From the wiki for [Filesets]([https://github.com/boot-
clj/boot/wiki/Filesets](https://github.com/boot-clj/boot/wiki/Filesets))

" _Build workflows necessarily involve the filesystem because it 's not
practical to send file contents around in memory as function arguments, and
because we want to be able to leverage existing JVM tooling that generally
operates on things in the class path and not on in-memory data structures._"

so like unix pipes? What exactly is impractical about passing big values as
function arguments? Isn't that how gulp works?

~~~
michaniskin
Well, there are two things there: the unbounded potential size of files and
the ability to coexist in the current JVM ecosystem without rewriting every
bit of code that looks for things on the class path.

I think that generally the files you're dealing with will fit in memory, but
you still wouldn't probably want to have everything in memory all the time,
you'd need to stream them (consider an uberjar that's 10M as a JAR, but might
contain contents that are 10x that size uncompressed).

This brings us to the second point. No existing JVM tools are prepared to
accept files via pipes. Tooling on the JVM looks for things on the class path
and in JAR files. We definitely don't want to have to rewrite every tool to
use some in-memory pipe system.

The fileset and pod abstractions provided by boot work together to give you
the best of both worlds--an immutable representation of the filesystem and
class path combined with full interop with the existing JVM ecosystem.

Another issue with Unix pipes is that they are not awesome for tree-like
things. In bash you pipe lines of text from one program to another, but tree
processing is very difficult. Consider xml processing by pipes, or my jsawk
library for processing JSON in the shell. These suffer from memory issues
because it's hard to stream trees (if you have a 2G JSON file that is a single
object jsawk can't even read it in).

------
smrtinsert
Interesting that a fileset concept has emerged. I would draw parallels with
Ant, but this project seems to have already zoomed past ant for ease of use.
Can boot be used to build pure java projects as well?

~~~
michaniskin
I don't see why not. There is a javac task included with the built-in tasks
that ship with boot itself, but boot is designed for ease of extension so you
can write tasks to implement your particular workflow. You can even write
tasks that use Ant or Maven in a pod (pods are a sort of first-class
implementation of isolated classloaders in which work can be done). We even
have a jRuby task now that can be used as a component of a Ruby build
pipeline, so yes, I think boot would be a great way to build Java projects!

------
amatus
Does it build hoplon yet?

~~~
michaniskin
Not yet, the hoplon task hasn't been ported yet. But very soon, I promise :)

