4 ms·
I've used pretty much this approach at a couple of places, mostly working with Java. A production server is a vanilla Red Hat machine with an aftermarket JDK at
by twic 6y ago
I've used pretty much this approach at a couple of places, mostly working with Java. A production server is a vanilla Red Hat machine with an aftermarket JDK at a known path. The deployment artifact is a zip file containing jar files (and anything else) and a shell script called run.sh. Deployment is copying, unzipping, and overwriting a symlink. A cron job or a systemd etc service starts it. CI is a cron job which pulls, runs build.sh, and copies build/distribution to an NFS server. It works.
- madhadron 6y agoYou can also build a fat jar, which is basically a zip file containing everything but that the JVM knows how to load. All the static assets can go in there, too. It saves you the build.sh.
- regularfry 6y agoI thought recent JDKs had the tools to build executable jars with the JVM built in. Can't find a reference now, though.
- kondu 6y agoPerhaps you're talking about jpackage - https://openjdk.java.net/jeps/392 https://openjdk.java.net/jeps/392
- regularfry 6y agoThat sounds close, but I thought you got a plain executable out rather than an installer.
- twic 6y agoThe build.sh is how CI builds the project from source. I suppose you meant that it saves the run.sh - but it doesn't, because you still have to give the path to the JDK, and any JVM command line arguments you want. Honestly, i've never really got the point of fat jars. Fat jars come with all sorts of annoyances (what do you do with the manifests from each jar?). Unpacking a zip is not hard.