shadow VS jib

So: I am making a JavaFX application to act as a remote console for my server. I'm the only person that will have a copy of it, so it doesn't need to be snazzy or 100% efficient. I have turned the project into a jar via ShadowJar, turned that into an EXE via Launch4j, and yesterday turned that into an installer via Inno.

I’ve never tried this and I I’m not libgdx expert, but you can try running a Uber jar with shadow. it’s the Gradle equivalent of the shade plug-in for maven builds.

When you get into a situation where you need to sandbox a dependency within another, including this example, where you want each of your dependencies to get its own unique instance of their dependency, you can "shadow" the dependency that is to be sandboxed this way. Look into https://github.com/johnrengelman/shadow.

Try using the shadow plugin for gradle https://github.com/johnrengelman/shadow

and also apparently, it's a problem with shadowJar itself https://github.com/johnrengelman/shadow/issues/713

Behind the scenes, Shadow creates a FatJar with all the things we may need in the future.

Note: **According to Serverless documentation you can use the command **serverless deploy -v. However, with Java-based-projects that’s not true because it needs to create a Fatjar with all the needed requirements (so the command will fail). By default, Serverless will set **shadow** as a dependency in the gradle file for those purposes. The deploy command will generate a build file called -all.jar that is the one that’s going to be uploaded to the AWS Lambda function.

The result .jar is going to submitted to Apache Spark cluster (e.g. spark-submit command). So, it should contain all runtime artefacts. Unfortunately, the standard Spring Boot packaging does not put the dependencies in the way Apache Spark expects it. So, we'll use shadow-jar Gradle plugin. Take a look at the example below.

I've writen many Kotlin+Gradle projects that produce jars without the shadow plugin. They're not fat, shaded, standalone executable jars though - is that what you need?

You need to build Docker images for each app. This is specific to the JHipster application used in this tutorial which uses Jib to build the images. Make sure you are logged into Docker using docker login. Navigate to each app folder (store, invoice, product) and run the following command:

JIB

It is pretty easy to do with https://github.com/GoogleContainerTools/jib.

Save yourself the dockerfile and use jib: https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin

I first learned about Distroless because it was the default option in Google's Jib. Jib is a Maven plugin to create Docker containers without dependency on Docker. Note that the default has changed now.

Optimize your Dockerfile by using a small base Java Image, use either Spring Boot's layers tools or Google Jib to build your docker file, and increase CPU/Memory requests and limits if you can.

In this section, we will setup the automated generation and deployment of a Docker container image. You will need a Docker Hub account and the Jib Gradle Plugin.

If you don't want to hack on your own scripts to package your app into a container, I can recommend the JIB maven plugin. A gradle version is also available.