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