Set up binary distribution mechanism

[jboynes]

Maven's deploy phase can be used to publish the built binary, both for development SNAPSHOT releases and for production ones. You can deploy to Maven central or to Bintray; both give free accounts to OSS projects (IIRC). We should do this anyway to publish non-executable artifacts like the jar from -core.

GitHub also provide a way to distribute files so the binary could be uploaded to there.

One the tests pass, this can be automated with Travis so that it happens automatically on each push to master.

[rob42]

How will this work for a noob install? Can a git clone or some other simple process pull the jar down as part of the process? Im open to any ideas, including containers etc, so long as the process is automated.

[jboynes]

For a user who is planning to modify the code, we can assume they have the tools needed: Java, Maven, etc. They would clone this repo and run mvn package as a first step. They will need to able to do this make changes...

For a user just looking to run the server, it would depend on their environment. Ideally, we would provide a native installer and distribute through a platform store (Windows, Mac, Debian etc.) so they could just install it. That needs some work to set up though (developer accounts, signing keys etc.).

In the meantime, if we assume users have an environment able to run Java (i.e. they have a JRE installed), we can upload a simple archive for them to download. I'd suggest a .zip and/or .tgz archive containing an installation directory with bin, lib, conf directories as needed. The assembly plugin can produce that automatically. This matches how Maven, Tomcat, Jetty etc. install. The archive can be hosted on GitHub (in the releases area), in Maven Central/Bintray as a searchable/downloadable artifact. User would download a link off our pages, unzip/untar the archive, and be set to go.

We can also post an image to Docker Hub for users who have Linux/Docker installed but not a JRE. The image would handle pulling all pre-requisites including Java. This would be easier for users already having Docker as they could just docker run ... the image. I'm not sure how common having Docker installed/installable is on the type of systems where this would be running and this might be a bit future looking.

Travis can build all of these artifacts and publish them automatically based on tagging the repo for a release. You need to be a collaborator on the project to set that up though. I can do that on my fork and then you can copy it over, or if you want to add me here I can set it up directly.

[rob42]

I used the download and unzip method in my freeboard project. It caused constant problems for windows as there are so many versions, and so many incompatibilities between them. Basic stuff like java location and env behaviour, firewalls and viruscheckers. Plus the muggle user problems of unzipping it C:\my boat's really cool app\ directory. Even on the RPi, with a script, its amazing how users can do it wrong.
Wonder if there is a way to prune the bin history?

[rob42]

Found https://rtyley.github.io/bfg-repo-cleaner/, which should be able to clean up the bin files.
Since we can assume the user has git, the shell script could pull a bin from a distribution site before starting...or just use the cleaner to only keep a few bin versions?

[jboynes]

Yeah, Windows poses a bunch of challenges. But I think those also apply to the current approach of cloning a git repo and just need very defensive implementation and good diags.

There are ways to rewrite history (ninjad I see) but they are disruptive to people who have forks. We could clean current binaries but would not want to keep committing them.

[jboynes]

I suggest we start here by separating the assembly steps from the server code. I'll create a PR that adds some sub-modules that handle the assembly and allows the libraries to be pushed via deploy. git clone; mvn package will still work while we figure out the distribution of those packages.

[rob42]

The biggest advantage of the git clone method was distributing updates. After a fix or whatever the user just does git pull. With the zip method that caused chaos at update time, especially if it required many tweaks or 'try this'. Its easier to get them to do git checkout fix-for-joe etc.

mvn package assumes mvn is installed.

[rob42]

I have set up a new project (signalk-java) which solves this problem. Still needs more testing etc, but appears to offer all the required features without storing any binaries.
Leaving this open till that project is proven.

[rob42]

The signalk-java project seems to work well. By default a mvn install will build the release build which uses jitpack.io to grab tagged versions ondemand. Developers use the mvn -Pdev install which builds from the projects on your local maven repo. Hence its possible to work changes across core, server and signalk-java without going through jitpack, but for less skilled users it just automates the deploy.

And no stored binaries!