Clojure build tool Boot 2.0 RC1 out now

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

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

[3] https://github.com/lynndylanhurley/generator-gulp-of-drano/b...

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

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).

Actually I should mention that perhaps the wording in the passage you quoted is misleading. We don't send the actual file contents around in memory as function arguments, but the fileset object itself _is_ passed in memory as an argument, and this fileset object contains the metadata you need to perform your work. When you need the contents of the file there are protocol methods for obtaining the underling file contents, and the actual underlying files are completely anonymous temp files of no special significance (their specific locations in the filesystem are irrelevant to the build process).

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!

Sure! A minimal Java project with boot might look like:

    mkdir -p boot-java/src
    cd boot-java
    echo 'public class Main{public static void main(String[]args){System.out.println("hi!");}}' > src/Main.java
    boot -s src/ javac jar -m Main
    java -jar target/project.jar

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