
Capsule – Package and Deploy JVM Applications - slantedview
http://www.capsule.io/
======
kodablah
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...](https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-
contained-packaging.html) 2\. [https://github.com/sbt/sbt-
assembly](https://github.com/sbt/sbt-assembly) 3\.
[https://github.com/sbt/sbt-native-packager](https://github.com/sbt/sbt-
native-packager)

~~~
pron
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).

------
Frozenlock
> 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?

~~~
pron
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.

~~~
jwr
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)?

~~~
pron
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.

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

~~~
pron
See my other comment about Capsule Shield:
[https://github.com/puniverse/capsule-
shield](https://github.com/puniverse/capsule-shield)

~~~
_Codemonkeyism
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?

~~~
pron
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.

~~~
_Codemonkeyism
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, ...)

~~~
pron
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...](http://blog.paralleluniverse.co/2015/08/07/scoped-
continuations/)

------
_Codemonkeyism
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](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.

~~~
pron
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](https://github.com/puniverse/capsule-shield)

~~~
_Codemonkeyism
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.

------
Randgalt
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](https://github.com/chrischristo/capsule-maven-plugin)

------
vbezhenar
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.

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

------
rozap
> 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.

~~~
pron
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/](http://www.capsule.io/caplets/)

------
CJefferson
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.

~~~
kodablah
This exists in the Java 8 JDK:
[https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...](https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-
contained-packaging.html)

------
mingodad
There is also this alternative
[http://oss.readytalk.com/avian/](http://oss.readytalk.com/avian/)

~~~
pron
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.

