[pron]

Well, you can choose to embed the dependencies in the capsule, but I think the best approach for production deployment is have an organizational Maven repository (Artifactory/Nexus). This way you upload the libs, and the jars containing the actual apps to your repo, and all you need to do is restart the capsule (it can be configured to load and run the latest version).

[twic]

So you're downloading jars from the repository to the production server when the app starts? I would feel very uneasy about that kind of coupling.

And i still don't see what advantage this has over just pushing out normal packages.

[pron]

I feel uneasy about deploying the wrong version. With capsule, at launch it checks for a new version in the repo (if you configure it to use the newest version rather than a specific one). The packages are only downloaded once: not on every restart.

Alternatively, you can embed the dependencies, in which case it's just like a "normal package", only it doesn't require installation, and is just as easy to create (your build tool can create it). So it's a platform independent "normal package", with added features.

[twic]

Interesting. I feel much more confident about deploying the right thing using an operating system package than some other mechanism. Almost everything else in the datacentre is deployed using operating system packages, so we get a lot of practice at deploying the right versions of things. The few legacy applications we have that are deployed via custom mechanisms are a headache - they require completely different tooling and troubleshooting knowledge to everything else.

But then, i have spent a fair amount of managing machines, shuffling packages around apt repositories, writing Puppet code and so on. Perhaps for a developer who has not served a sentence in operations, operating system packages are a less comforting proposition.

You seem to be very keen on avoiding "installation". Could you tell us about why that is?

And could you remind me what the added features of a capsule are? Putting aside the differences in delivery mechanism, which as i've said, i'm afraid i see as misfeatures, the only one i see is that it automatically finds the right JRE.

(Sorry you're being downvoted, by the way. I think this is an interesting discussion, and your gracious responses deserve upvotes, not downvotes.)

[pron]

The advantage Capsule gives you is statelessness. The user does not need to put her system in a certain state. You get one file and you run it. It should work regardless of anything else that's installed -- or not -- on your machine, with the exception of an OS and a JRE.

There are other ways to achieve stateless deployment, and Capsule is not always the right fit. For example, it's not the right fit if your app requires an Oracle DB installed locally (it could be done, because Capsule supports an installation script embedded in the JAR, but that probably wouldn't be a good idea in this case). But when it is the right fit (e.g. microservices, grid workers etc.), it's much more lightweight than any other solution.

[bruceboughton]

So your production application can potentially run in an untested configuration because someone has pushed a new version of XyzLib.

Again, for what advantage?

I mean, fine if you want to do that. But I wouldn't call it Modern Java or recommend anyone else do it.

[pron]

How is that any more dangerous from deploying and installing an OS package? It's very hard to accidentally deploy to a release Maven repo. Maven Central makes you jump through hoops, and organizational repos have their own safeguards. They already deploy everything to their Maven repo anyway, why deploy again?

And if you don't want to enable automatic upgrades, you still get stateless, installation-free deployment.