Is there a tool you can use to detect when the same class is defined in multiple dependencies? I am looking at how we can catch these things before it hits runtime

I don't recall separate thing for that but two things come in mind: use shadow plugin to aggregate all this jars (even if you don't use is result) and you'll get relevant warning. Another way is to use a copy task working on the contents of all that dependencies (including only class files) with duplicates strategy == fail/warn.

hmm ok, thanks. I am trying to move from shadow jar to thin-jar style packaging, and so seeing if I can retain the build-time resolution of multiple classes. so using shadow jar just as a way of generating a warn might be a decent first pass at this

And what do you use for thin jar? I migrated to spring boot plugin for that (even for projects without spring) since they have good loader and uber jar layout.

I am moving to a jib-based build using the beryx runtime and jlink plugins

Aah, I use something similar for project on Quarkus (their fast-jar + jib for container build) but without repackaging jdk

I recently learned that the Android Gradle Plugin does this out of the box when processing the class files. Would be nice to have a similar solution for ‘plain’ Java development. The plugin looks like it can do that. Thanks for sharing.

I am moving to a jib-based build using the beryx runtime and jlink plugins

Just a personal opinion from doing the same recently: don't It is very inflexible and the developers too. I had to jump several hoops to get it running like expected, including using the filter plugin to exclude all files they include and define my own layout to make it work properly. And the final strike when I switched to a proper Docker build was, when I tried to use the Java 8 image as base because it is smaller than the Java 17 image and I have my own runtime image and Jib didn't allow it as a measure to protect people shooting their own feet, but without an option to suppress or downgrade this check and without them even considering adding it. Now the build runs perfect and the image is approximately half the size with

debian:stable-slim

as base. (I couldn't use it as base image for Jib, as I need font support which doesn't work with it but needs an additional Debian package)

Interesting. So far I have not had any issues. That filter plugin thing, was that because of the default extra directories they set?

@Vampire, could you share what do you choose in the end? Plain `Dockerfile`s, custom plugin or something else?

Plain

Dockerfile

combined with Ben Muschkos Docker plugin to build and then save the Docker image to a tar.gz archive.

Oh I didn't know the bmuschko plugin could do tar.gz I thought it only built against a docker daemon

Interesting. So far I have not had any issues. That filter plugin thing, was that because of the default extra directories they set?

Actually more because of the whole concept. I don't want

java

as entry point directly. I want the project runnable according to

application

plugin without Docker too and for example give paths to the application via the start script and so on. I could of course also make Docker case specific logic, but it wanted it consistent, also because I develop and test with the application version and only have it in the Docker container for easy distribution and management, so I wanted it as similar as possible. So I basically ignored all files added by Jib, added the files "again" via extra directories and created layers as I wanted.

Ah OK. What is the version check thing? Thanks for going through this, it helps me know what to look out for.

As I said, I wanted to use a Java 8 base image for a Java 17 project as it is significantly smaller and Jib doesn't allow it as described above. I could of course have worked around that too by creating another Gradle subproject just for assembling the Docker image that is not a Java project, but at that point I was sick of jumping hoops just to make Jib happy and just accepted that it is only suitable for small standard projects and not if you need flexibility

Hmm OK. I don't think our use case would be effected by that. We are using jdk11 base images fir our java 8 and java 11 projects, but with jib we are also supporting a custom runtime built with the beryx plugin, so we use a base image with no jdk for that mode

If you don't need font support, that's probably fine. Otherwise you need a custom base image for example, as described above. 🙂

Yeah we have some custom base images we use fir certain projects, but its still jdk11 so all our java 8 and 11 projects are fine with it

If you have custom base images, the version check does not affect you anyway, only some known base images are checked

Ah OK. That does seem like a weird feature though

Well, it is a shoot-yourself-in-the-foot protection, so that you do not try to run a Java 11 program with a Java 8 image and similar. The check is great generally, if it just were disableable where not applicable.

Yeah, fair

Generally good thing for almost any checks. Otherwise it will always try to bite for some corner case or another.