Feature/buck support

[illuminace]

Resolves #32 Support for Buck

This PR covers basic support for Buck. The user is expected to include the vertx-hot-buck fat-jar in a run utility module, and configure it using BuckHotDeployBuilder in a main method, to be run via IDE or CLI. It supports buck build and buck fetch (crudely), with defaults tailored for a java_binary build rule. From thereon in, functionality should be similar to the Maven plugin.

The codebase has been split into the core hot-deploy functionality, and separate Maven plugin and Buck adapters that depend on core.

The Buck compiler itself compiles to a native executable; there are no handy Java hooks to integrate with, and no dlls for JNI. So this Buck implementation simply invokes a Buck binary, which is expected to be present on PATH.

When building projects with Buck, one stores configuration in a number of places, including a .buckconfig configuration file and nested BUCK build files. There is some churn on these formats, and some complexity involved in interpreting them, so instead of dealing with the complexity and coupling involved in understanding them, this implementation just relies on a combination of (hopefully) sensible defaults, and user-provided configuration via BuckHotDeployBuilder.

This implementation probably isn't sufficiently configurable or efficient for substantial Buck projects, but should suffice for some simpler projects, and will no doubt be extended and improved as required.

Known Deficiencies

• Some of the Buck tests depend on a native buck binary existing on the classpath, which is not the case on Travis, and thus these tests are unfortunately skipped on the CI server. Far from ideal to say the least.
• There is more to be done around nicely encapsulating properties for the different build systems
• There is a lot of missing functionality. Support for .buckjavaargs, invoking buck project, a more efficient buck fetch policy, greater classpath intelligence, etc.
• It has only been tested on a couple of trivial projects that have similar project structure (read: there are liable to be problems)

[dazraf]

looks good thanks!

[dazraf]

to activate the tests in travis ... i wonder if we can download an os specific build of buck binary during the build ...

[illuminace]

I don't think the Buck team publicly host builds - their advice centres around manually building it. I haven't found anybody else hosting them either.

Having just had a slightly better look over the buck build, the c/cpp component is irrelevant for our purposes - we're mainly talking java with python and bash wrappers. That said, it still wouldn't be clean.

There isn't a simple build artefact to pick up and either check-in or publish to a fileshare: I'd have to package all the relevant build output (jars, bytecode, any wrapper scripts) in some fashion. A simple compressed archive would work, but we're talking a fairly large file - maybe 100M - driven by a configured java classpath configuration. I guess I could wrap that with a simple bash script to provide something executable. However you look at it, we're talking either a substantial increase in the vertx:hot repo size, or substantial network traffic to a fileshare somewhere.

Building from source is an alternative option, but isn't enticing; since the Buck chaps like to check-in their dependencies, their repo isn't all that far short of 1G, and build-time is a consideration too.

I'll let the idea percolate... I'm just not too keen on bloating this repo with hundreds of megs of buck-ery, nor on kicking off large network file transfers during a test run. Any thoughts welcome.