Support JAR-based deployment without container

[remmeier]

So far the microprofile like JEE have focus on container-based deployment. But with the general trend in the direction of microservices and orchestration platforms like kubernetes, there is not much use left for container architectures. Barely two applications get deployed within the same JVM process and as such there is no need to introduce a container layer between the orchestration infastructure and the application. This not only simplifies the architecture of the application, but also starts to enable much more simpler unit testing without having to (externally) launch the container or rely on technologies like Arquillian. A CDI Test Runner like Deltaspike could take care of testing in such an environment.

What would be needed by a microprofile vendor is a JAR for each specification (servlet engine, JAXRS, health, etc.). Application are then free to choose which features of microprofile to use. Currently lacking in specification is a configuration mechanism for the various parts of the application and an API to manage the http server/servlet engine.

the move would align with Java9/Jigsaw. Possibly would allow the use of AoT in the future. And vendors could, for example, further opt for a https://google.github.io/dagger/ CDI implementation that would move many of the preprocessing step of a tradition start into the compile phase, making applications more lightweight and faster to boot, while catching more errors at compile-time. This probably would also align quite well with projectfn and other projects in the area, as microprofile would gain the necessary speed to launch very quickly.

[kenfinnigan]

Do you mean MicroProfile should support executable jars? (ie. fat jars)

Or are you suggesting each vendor implementation of a specification in MicroProfile should be available as a Maven JAR dependency that can be added to a project's dependency set?

[remmeier]

Maven JARs would be perfect. Allowing to add the requires features to the classpath of a regular Java SE application.

Personally I don't like the far jars ,icj due to the additional processing step involved when building them. I'm already perfectly ok having all the JARs in a directory, which then usually goes into an RPM or Docker image.

whether Maven JARs of different vendors would be compatible with each other would be another question. Or whether people would have to stick to the Maven JARs of a single vendor. Ideally the former would be great to have.

I think all this could make microprofile and maybe EE4J really stand out again and also move beyond what is currently possible with Spring/Spring Boot, which has become a bit chubby and sluggish...

[tomwhoiscontrary]

If i've understood correctly, the basic idea would be that there is someway to package a microprofile application for deployment to an environment that has a JRE but no application server. So i would be able to do something like:

./gradlew build
scp build/distributions/myapp.zip app@server:/tmp/myapp.zip
ssh app@server unzip /tmp/myapp.zip -d /opt/apps
ssh app@server /opt/apps/myapp/bin/myapp

And my app is running.

I personally am a huge fan of this kind of deployment. It's great to have such a minimal requirement from the environment - just a shell, unzip, and a JRE. Needing an application server installed has always been a considerable barrier to using anything EE-related in the modern trendy cloudy companies i've worked in.

This doesn't need to be a fat jar, or involve some complicated bootstrap mechanism. It would be fine to lean on build tools (eg Gradle's application plugin) or let users use their own existing mechanisms (my current team has a suite of scripts at the heart of which is export CLASSPATH=$(find lib -type f -name '*.jar' | sort | tr '\n' :)!).

[OndroMih]

I've created a document proposing a specification for FAT JARs a while ago, but I haven't had enough time to push that forward: https://github.com/OndrejM/fat-jar-spec If enough people are interested, I can raise it as a PR to this repo. First please review and let me know if it's somewhere close to what you would expect. E.g. give a thumbs up to this comment s that I know how many people are interested.

[kenfinnigan]

@OndrejM, what would be the benefit of standardizing an uber JAR format?

Usually standardization is a means to allow applications to be ported between implementations, and I'm not sure how that comes into play in terms of the packaging.

[remmeier]

yes, I envisioned it exactly as stated by @tomwhoiscontrary . No need for fat jars or any other complicated. Just java -jar with a directory of JARs added to the classpath. For example, in Gradle the "application" plugin can create then a zip out of such a thing with a shell script to launch the java process. From there there are Gradle plugins will package the application into docker, rpm/systemd, etc. With jlink one could even eliminate the need for a JVM.

if somebody likes the use of fat jars, he can still do that on top of it.

[kwsutter]

Just reviewing old Issues for cleanup... As I read through this, the suggestion doesn't seem to apply to the MicroProfile programming model. This is more of a packaging suggestion, which would apply to the implementers of MicroProfile. I'm not seeing anything that is being proposed for the MicroProfile specifications or APIs. Am I missing the point? If not, then I'd like to close this Issue. Thanks.

[tomwhoiscontrary]

@kwsutter I think you're right. If packaging doesn't fall within the bounds of the MicroProfile spec, then nor does this issue.

May i say, thanks for actually looking at issues before closing them! The usual thing these days is just to mass-close any issue that hasn't been touched in a while, regardless of whether there is any value to it.