6 ms·

Capsule – Package and Deploy JVM Applications

71 points by slantedview 11y ago

rozap 11y ago
> 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 11y ago
  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/
- yrro 11y ago
  I wrote a Caplet to add extra directories on the host system to the classpath of the JVM that ran my application.
Randgalt 11y ago
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
Frozenlock 11y ago
> 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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        I might partially agree, though point 2 went away for us with Docker.
        pron 11y ago
        See my other comment about Capsule Shield: https://github.com/puniverse/capsule-shield https://github.com/puniverse/capsule-shield
mingodad 11y ago
There is also this alternative http://oss.readytalk.com/avian/ http://oss.readytalk.com/avian/
- pron 11y ago
  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.
vbezhenar 11y ago
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 11y ago
  Well, they have to to set java command line arguments. Capsule solves that.
_Codemonkeyism 11y ago
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.
- konradb 11y ago
  > 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?
  - _Codemonkeyism 11y ago
    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)
    - johnbellone 11y ago
      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.
kodablah 11y ago
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/deploy/self-contained-packaging.html https://docs.oracle.com/javase/8/docs/technotes/guides/deplo... 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 11y ago
  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).
CJefferson 11y ago
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 11y ago
  This exists in the Java 8 JDK: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
- pron 11y ago
  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.

71 points by slantedview 11y ago

rozap 11y ago

> 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 11y ago
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/
yrro 11y ago
I wrote a Caplet to add extra directories on the host system to the classpath of the JVM that ran my application.

Randgalt 11y ago

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

Frozenlock 11y ago

> 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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      I might partially agree, though point 2 went away for us with Docker.
      - pron 11y ago
        See my other comment about Capsule Shield: https://github.com/puniverse/capsule-shield https://github.com/puniverse/capsule-shield

mingodad 11y ago

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

pron 11y ago
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.

vbezhenar 11y ago

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 11y ago
Well, they have to to set java command line arguments. Capsule solves that.

_Codemonkeyism 11y ago

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.

konradb 11y ago
> 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?
- _Codemonkeyism 11y ago
  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)
  - johnbellone 11y ago
    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.

kodablah 11y ago

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/deploy/self-contained-packaging.html https://docs.oracle.com/javase/8/docs/technotes/guides/deplo... 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 11y ago
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).

CJefferson 11y ago

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 11y ago
This exists in the Java 8 JDK: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
pron 11y ago
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.