Proof-of-concept for distributing executable binary

[eboto]

Uses the coincidentally named alexarchambault/coursier as part of the build to generate a small (12kb) executable binary featuring all courier modes.

Figure this thing is small enough to just distribute here in github (bin/courier), removing requirement for bintray or any other binary distribution solution.

Try it out from the command-line (from courier project root)

sbt dist \
  && \
bin/courier \
  ts \
  target/test-courier \
  reference-suite/src/main/courier \
  reference-suite/src/main/courier

[saeta]

Hey @eboto thanks for this. Really funny naming coincidence.

Couple comments:

• Glad to see some investment in making a CLI executable that's easy to use for generation code. :-) Internally, we build "executable fat-JARs" using a combination of sbt-assembly and the following code snippet:

executableFile <<= (projectID, assembly, target) map {(projectId, assembly, target) =>
  val exeFile = target / projectId.name
  IO.write(exeFile, """#!/bin/bash
                       |exec java -jar $0 "$@"
                       |
                       |""".stripMargin)
  IO.append(exeFile, IO.readBytes(assembly))
  exeFile
}

I'd prefer if instead of downloading a bunch of additional jars upon command execution, we'd instead download a single "fat-JAR" that only requires a JRE on the system to execute. (No network calls required.)

• I've recently fixed the publishing issues with the sbt plugin. As a result, I've worked with Bintray to get that all set up. I'm reasonably convinced that we should move the hosting of the tool executables to bintray and not have them clog up the git history.

Are these changes something you'd be willing to help make?

[saeta]

Note: all the rest of your changes look great. :-)

[eboto]

Hey @saeta ! Thanks for the info. Also sorry for the long delay -- believe it or not this is the first time I've found a quiet moment to program in spare time for weeks!

I was wondering how coursier were making executable java binaries, and I bet they were using the same trick you just described! Cool to learn that.

Yeah I see your point about network connections. Half of me says "Well if you're downloading the jar then you need a network connection anyways, and if you've executed it once you don't need a network connection the second time", but there are bound to be users that drop the ball there, forget to execute it the first time, and end up with a useless executable later on when they're trying to code from an airplane.

Long-story-short: A fat jar sounds appropriate.

I'll make the change to strip coursier.

[eboto]

OK that should do it! running executableFile in the courier-cli project generates an executable fat jar in cli/target/courier

[saeta]

Wow, super speedy work! And I fully understand what you mean by not finding a spare moment. That looks great. I've now played around with Bintray, so I'll see if I can get this published today. Merging...