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