jib

We use Google Jib with Gradle (https://github.com/GoogleContainerTools/jib) and love it. It does some slight optimisations (just use the classes rather than jars) and removes some decision making about where files are laid out. It also builds into the Gradle lifecycle neatly. I don't need a separate tool for building images. I'm sure writing Maven xml wouldn't be fun though!

Use jib (java image builder) with maven or gradle and it will build an image with distroless-java plus your app: https://github.com/GoogleContainerTools/jib https://github.com/GoogleContainerTools/distroless/blob/mast...

https://github.com/GoogleContainerTools/jib#what-is-jib > What is Jib? > Jib builds optimized Docker and OCI images for your Java applications Funny. Here I thought you could just build and deploy a jar if you were committed to writing Java... I suppose it does make sense that "all things come to docker/containers", though. Allowing both golang and Java services to be deployed in the same manner.

This is what I think is the most practical approach. Pinning down ALL your dependencies to the exact version is much harder than it sounds. What you’re describing sound like the way Jib [1] does it. The pictures in this [2] blog post help visualize it. The reason I like the approach you describe is because it keeps things simpler at the start of a project and consistent across most projects. I also think it makes sense to have those support containers build on a schedule. For example, you build your build/CI container weekly and that’s the CI container for the week. On demand project builds use that CI container which has all dependencies, etc. baked in. It would be nice if CI systems would let me explicitly tag builds as (non)reproducible. 1. https://github.com/GoogleContainerTools/jib 2. https://phauer.com/2019/no-fat-jar-in-docker