Capsule – Package and Deploy JVM Applications | Hacker News Reader

Capsule – Package and Deploy JVM Applications

capsule.io

71 pointsslantedview30 comments

I admittedly have not read the docs yet and I'm curious how this compares to Java packaging[1], SBT assembly[2],and SBT native packager[3]. I understand that containerization is a feature, but I am unsure how it improves over a simple Dockerfile using one of the aforementioned packaging solutions.

1. https://docs.oracle.com/javase/8/docs/technotes/guides/deplo... 2. https://github.com/sbt/sbt-assembly 3. https://github.com/sbt/sbt-native-packager

See my other comments but the short answer is that fat-jars often fail, and Capsule offers more -- and more versatile -- deployment solutions than native packaging (which is mostly used only by desktop apps).

> Distribute a Clojure application without embedding Clojure itself in the capsule, and have Clojure downloaded the first time the capsule is launched. The Clojure runtime will be cached and shared among all Clojure capsules so it will only be downloaded once.

How would that be useful?

Your artifacts would be smaller (the Clojure runtime is ~4MB; the Scala runtime is ~5MB) and you could even have the runtime auto-update if you like. But the main point is just to show how flexible Capsule is, and how you can have the deployment adapt itself to the environment in many ways.

I think "smaller" is not what we should be chasing. Given drive sizes and network speeds, I'd much rather have "simple and reliable" than "small". In other words, I prefer to save my time rather than my computer's time.

As for the project, I'm trying to understand what it provides over "lein uberjar" that I'm already using (and happy with it)?

1. Uberjar doesn't always work. It may cause resource collision (and even shading doesn't always work as some libraries are resistant to shading). It also doesn't support native libraries. Capsule always works and is just as easy to build as an uberjar with the lein plugin.

2. Even with an uberjar you need a platform specific startup script (to pick a JVM version, set JVM flags, set up a boot classpath if you need it or agents if you need them). With Capsule, all of that is stored as metadata in the manifest, and the capsule sets up everything on its own.

3. Capsule provides other features, such as launching itself inside a container (and it's better than Docker because the container is unprivileged, and doesn't require an image), packaging as a native application (with icons etc.), launching itself as a daemon/service and more.

I might partially agree, though point 2 went away for us with Docker.

See my other comment about Capsule Shield: https://github.com/puniverse/capsule-shield

You're from Parallel Universe? I've played with the idea of a programming language, looking for an async layer that supports Scala style Future[T]s. Possible with Quasar?

Not entirely sure what you mean by "the idea of a programming language". Scala-like futures are already in the JDK as CompletableFuture. Quasar is something different (and, I believe, better): it provides true fibers (aka lightweight threads), just like Erlang or Go.

I've meant playing with the idea for a programming language.

With Future I've meant would it be easy to put a Future based API which I like b/c of composiblity on top of Quasar, e.g. on top of fibers.

(Futures are just an API to concurrency not concurrency itself that can sit on actors, forkjoin, ...)

Then sure. But check out this talk/blog post, which explains why such monadic futures are not a good way to compose asynchronous code: http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...

About Java packaging:

My personal feeling is that the local install approach of gem/npm has won over the pull dependency approach of Maven/Ant - at least for development, but I think also with Docker approaches.

Java will address this with Jigsaw in Java 9 at last.

http://openjdk.java.net/projects/jigsaw/doc/quickstart.html

Capsule seems to be pulling dependencies if not packaged.

But we switched to JAR/Docker deployments for Scala some time ago with Jetty instead of WARs and so Capsule is welcome and we'll definetly try it. Hope it will switch to supporting Jigsaw with Java 9.

> My personal feeling is that the local install approach of gem/npm has won over the pull dependency approach of Maven/Ant - at least for development, but I think also with Docker approaches.

What distinction are you drawing here, with local install vs pull dependency?

Whenever I've run maven it's created a local repository and saved all the dependencies in that, but perhaps I'm misunderstanding the distinction you are drawing?

My (unreflected) thoughts, wording not the best, but for me:

1. Push deps to an app means: npm install X

This makes it easier to promote libraries as it's easier to try them out. Just write npm install X and you're done.

2. Pull deps means: declare dependencies in your app and a package manager will download them.

This makes it harder to try libs you find on Github for my taste. It also ties dep management to packaging, where e.g. with Docker I prefer to manage dependency in the Docker file instead.

(npm can do pull too)

I do not seem to see the distinction you are trying to make. The fact that the former is available is a direct result of the latter; you _need_ to declare the dependencies somewhere in order to have an easy UX of `npm install foo`.

Where I do agree is that the maven UX is nowhere near as easy to use, but lately I have been using it over the Clojure facade and its been quite nice.

it's the exact same thing with a slightly different syntax. I do a lot of maven/sbt, and have done a lot of ruby/js and I think there's no difference but your familiarity with them.

if I could vote in either direction I think maven/sbt is actually easier because you don't need to deal with "global" install. very dumb feature to share packages across projects, much simpler to think about deps as always project specific. but then again no one forces you to use global install... so it's the same. it only gets bad once you need some hacky junk like rvm or virtualenv to achieve project dependency isolation.

I will take a big Pom file or build.sbt over having to remember to enable the right installation of Python every time I switch projects any day.

Capsule has a caplet called Shield[1] which is much better than Docker for JVM applications. It creates an unprivileged container, doesn't require building an image (still shipped as a JAR), and in a week or so it will also automatically handle piping logging and JMX monitoring out of the container.

[1]: https://github.com/puniverse/capsule-shield

Will take a look, but have the impression this one is lost. I'd (before reading) use Docker for easier recruiting, use the same for other deployments as well (Postgres etc.), more knowledge/best practices available etc.

I've just started using Capsule for an internal project. It's an excellent library. For our use case, we need to have a bash script that runs before the app starts. With capsule this is very easy. Also, because capsule doesn't do any shading, you don't run into the compatibility issues that shaders add. NOTE: I use the Capsule Maven plugin instead of Capsule directly https://github.com/chrischristo/capsule-maven-plugin

That's an interesting project! I always liked the simplicity of `java -jar` command. Instead of that simplicity, many project choose to roll huge startup bash+bat scripts or even worse, native launchers.

Well, they have to to set java command line arguments. Capsule solves that.

> Caplets are classes that hook into the capsule and modify its behavior.

What problem does this solve? Because it sounds like it is going to create quite a few new ones.

For example: launch a capsule in a container, run a capsule as a daemon/service, or turn a capsule to a native app. Other uses may include reading configurations from etcd/ZooKeeper or querying information about the host and using it to set better JVM flags.

See the list of available caplets: http://www.capsule.io/caplets/

I wrote a Caplet to add extra directories on the host system to the classpath of the JVM that ran my application.

Given many people's opinion of Java, and the mess of installing Java on windows (where the installer installs adware), I would prefer something which went as far as packaging a private JVM, so my users didn't even know (or have to care about the fact) I was using Java.

This exists in the Java 8 JDK: https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...

But such solutions already exist. While Capsule does have a caplet that targets the desktop but intentionally doesn't install its own JRE so that security and other updates could be installed -- some prefer it that way -- it is mostly geared towards server-side uses, where bundling a JRE is usually not the best solution.

There is also this alternative http://oss.readytalk.com/avian/

They're not at all alike. Capsule is a deployment mechanism for any JVM app and a JVM container solution (a "Docker for Java"). Avaian is an alternative JVM that supports a subset of Java.

Reply on news.ycombinator.com