This sounds pretty sensible. I wonder if there's a simple way to reproduce it. Maybe:<p><pre><code> I. Build your app as a thin JAR, with:
a. a Main-Class entry in the manifest
b. Class-Path entries in the manifest
c. a file containing a list of dependency coordinates (group, artifact, version) in META-INF
II. Write a shell script (for whatever value of 'shell' you like) which:
1. takes a Maven repo URL and a Maven coordinate (group, artifact, version)
2. downloads the JAR from the repo, extracts its dependency list, then pulls its dependencies too
3. (optionally) somehow records which JAR is the main one, say by writing a tiny shell script or a symlink pointing at it
</code></pre>
You might be able to use a standard embedded POM instead of a dependency list, which might reduce the work a bit, but that would then require doing transitive dependency resolution at deploy time, which is probably a bad idea.<p>Phase I is something like 10 - 20 lines of Gradle, tops. You could pack it up into a plugin easily enough. Phase II is a similar amount of shell script, maybe more.<p>For extra safety, add SHA3 hashes to the dependency list file, and check them when you download the dependencies.<p>I've described this as using a Maven repo, but that doesn't mean it has to hit Nexus or whatever; you can just put JARs in S3 in the right layout. A while ago, i was doing this by maintaining a repository locally, and just pushing the whole thing to a Bitbucket website:<p><a href="https://bitbucket.org/twic/twic.bitbucket.org/src/14ac48d4c4a9/repository/?at=default" rel="nofollow">https://bitbucket.org/twic/twic.bitbucket.org/src/14ac48d4c4...</a><p>You could do something similar, perhaps going from Nexus to S3.