Support OpenJDK S2I

[siamaksade]

When Using OpenJDK S2I to build and deploy the examples on OpenShift, builds succeeds but the deployment fails.

oc new-app java~https://github.com/quarkusio/quarkus-quickstarts --context-dir=getting-started --name=quarkus

The deployment fails with the following error since it can't determine which JAR file to use:

ERROR: Neither $JAVA_MAIN_CLASS nor $JAVA_APP_JAR is set and 2 JARs found in /deployments (1 expected)

sh-4.2$ ls /deployments/ -l
total 40
drwxrwxr-x. 2 jboss root     6 Oct 17 22:12 data
-rw-r--r--. 1 jboss root 34673 Mar  7 13:49 quarkus-quickstart-1.0-SNAPSHOT-runner.jar
-rw-r--r--. 1 jboss root  3353 Mar  7 13:49 quarkus-quickstart-1.0-SNAPSHOT.jar

[stuartwdouglas]

Try <uberJar>true</uberJar> in the maven plugin config

[siamaksade]

Do any of the quickstarts have it enabled to test with OpenShift?

[cescoffier]

No, the quickstarts are not using uberjar. Note that with uberjar you will be in JVM mode and not in native mode.

…

On 7 Mar 2019, at 14:56, Siamak Sadeghianfar ***@***.***> wrote: Do any of the quickstarts have it enabled to test with OpenShift? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vorburger]

@siamaksade @cescoffier I may be able to help with this one - will try to do so tomorrow or Monday...

FYI, background: fabric8io-images/s2i#123 is kind of related to this...

see also #304

[cescoffier]

@vorburger That would be awesome!

[geoand]

Using the uberjar config should do the trick since in that case we add the .original sufficient to the original jar, thus leaving a single .jar file.

[siamaksade]

It would be valuable to add a quickstart for OpenShift similar to getting-started-kubernetes and with uberjar config enabled

[geoand]

@siamaksade Good idea. What else would you like to see in that guide?

[cescoffier]

The last section of the kubernetes guide covers OpenShift.

…

On 8 Mar 2019, at 09:02, Georgios Andrianakis ***@***.***> wrote: @siamaksade Good idea. What would you like to see in that guide? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[siamaksade]

@geoand a quickstart like getting-started-openshift that possibly has also fabric8 in it and one can just run mvn fabric8:deploy, and that would create a build on OpenShift using the OpenJDK builder image and deploys the Quarkus app.

@cescoffier a guide is also would be great (#1306). One wouldn't even find it currently on quarkus.io since item in the guides page is called "Deploying Applications on Kubernetes" rather than "Deploying Applications on Kubernetes/OpenShift". Furthremore, it needs instructions on how to use S2I for the build, in addition to the docker build strategy.

[geoand]

If we agree that it is needed, I can definitely add it

[vorburger]

The last section of the kubernetes guide covers OpenShift.
One wouldn't even find it currently on quarkus.io since item in the guides page is called "Deploying Applications on Kubernetes" rather than "Deploying Applications on Kubernetes/OpenShift".

@siamaksade @cescoffier OK so let's fix (or further discuss) that point over in quarkusio/quarkusio.github.io#124 ...

It would be valuable to add a quickstart for OpenShift similar to getting-started-kubernetes and with uberjar config enabled

But if we can get oc new-app to work (original issue here; I'll look more into it next), then we may not actually need a separate getting-started-openshift anymore, no?

@geoand a quickstart like getting-started-openshift that possibly has also fabric8 in it and one can just run mvn fabric8:deploy, and that would create a build on OpenShift using the OpenJDK builder image and deploys the Quarkus app.

@siamaksade @geoand I'm personally actually not sure if I am huge fan of fabric8:deploy, and whether we should be further promoting it here... IMHO "normal" S2I on-cluster build from Git repo is what one would want to do to biuld from source? And to push local not yet committed changes, there's no need for a Maven plugin, but simply s2i build --copy . should do? To be tested and documented, of course.

[siamaksade]

@vorburger sure. I understand your reluctance toward fabric8 😃

[vorburger]

Try <uberJar>true</uberJar> in the maven plugin config

@stuartwdouglas @cescoffier see #1344 ...

I can see two solutions forward: a) I could do what's needed in the S2I Builder image to make it pick the (bigger) runner.jar over the (smaller) other normal JAR; or b) we could make the quarkus-maven-plugin produce only a single JAR? (Or do that jar.original rename thing but without bloating the runner JAR.)

Doing b) may be quicker, and would have the advantage that it would work for all S2I images (if I did the (a) solution it would be in https://github.com/fabric8io-images/s2i; the later the same would have to separately be redone over in https://github.com/jboss-container-images/openjdk because of fabric8io-images/s2i#218).

Note that with uberjar you will be in JVM mode and not in native mode.

Understood; this issue (for #1306) is about building a Quarkus app in OpenShift with S2i in JVM mode, not native. We'll tackle that later under #304.

[siamaksade]

(b) is preferable IMHO for reasons you mentioned. S2I builder image just sees 2 jars files and any heuristic for picking one would end up being the wrong choice for other use-cases.

[geoand]

I opened a PR (#1345) for b) - let's see what people think

[cescoffier]

Didn’t read everything, but if we could about the fat jar in a container that would be great...

…

On 8 Mar 2019, at 14:33, Georgios Andrianakis ***@***.***> wrote: I opened a PR for b) - let's see what people think — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cescoffier]

Can’t we have a builder that just take the regular runner and copy the libs?

…

On 8 Mar 2019, at 14:44, clement escoffier ***@***.***> wrote: Didn’t read everything, but if we could about the fat jar in a container that would be great... > On 8 Mar 2019, at 14:33, Georgios Andrianakis ***@***.***> wrote: > > I opened a PR for b) - let's see what people think > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.

[vorburger]

Didn’t read everything, but if we could about the fat jar in a container that would be great...

can you elaborate a little bit on why? I trust you have good reasons - I'd love to learn about them!

Can’t we have a builder that just take the regular runner and copy the libs?

we could, but that requires work in the S2I base image(s; several!), they probably won't know that they have to copy lib/ ... it's doable, but what's the "justification" ? Using uberJar for producing a FAT JAR may be the best solution after all, for the short term. (And sorry for the back and forth!)

[cescoffier]

A docker container is already your packaging unit, creating another packaging unit in it is just looking for bad performances at startup time.

In addition, we are creating a huge top layer and every update is going to resync the whole "fat" layer, which we would avoid with using the runner (as it's only your application code and resources).

[vorburger]

quarkusio/quarkus-quickstarts#81 now has a working (tested) proposed first version! That is still based on <uberJar>true. I have separately checked out if I can apply the idea from @gastaldi mentioned in #1345 to incrementally improve it, that's in quarkusio/quarkus-quickstarts#82.

[vorburger]

quarkusio/quarkus-quickstarts#81 has gone through some iterations, and we now have something (hopefully) final (now without <uberJar>true). @siamaksade hope you're OK if we close this issue after quarkusio/quarkus-quickstarts#81 and #1353 have been merged?

[vorburger]

@siamaksade OK for you to close this issue, now that both quarkusio/quarkus-quickstarts#81 as well as #1353 have been merged, and that quarkusio/quarkusio.github.io#126 is hopefully about to be merged?

[cescoffier]

This can be closed. quarkusio/quarkusio.github.io#126 need a bit of rework (very very small ordering issue).