Duplicate classes stemming from io.minio:minio artifact

As of version 6.0.0, the org.openmicroscopy:ome-common artifact depends on io.minio:minio:5.0.2, which depends on (among other things) com.google.code.findbugs:jsr305:3.0.1 and com.google.code.findbugs:annotations:3.0.1. Unfortunately, these two artifacts shadow some of the same classes from JSR-305 in the javax.annotations package. This causes the enforcer to fail when building projects that depend on ome-common 6.0.0:

Relevant portion of the build log
[WARNING] Rule 3: org.apache.maven.plugins.enforcer.BanDuplicateClasses failed with message:
No Duplicate Classes Allowed!
- For duplicate transitive dependencies, add dependency exclusions.
- For duplications between direct dependencies, resolve or add
  ignored classes to this rule's configuration.

  Found in:
  Duplicate classes:

  Found in:
  Duplicate classes:

I was looking into the best way to deal with it:

  1. I checked whether the latest minio, version 6.0.2, has addressed the issue, but it has not: same overlapping dependencies.

  2. There appears to be an issue in the findbugs GitHub repository documenting this issue—findbugsproject/findbugs#94—but it seems that FindBugs is no longer being maintained. Instead, there is SpotBugs now. So perhaps one action item here is to file an issue in the minio issue tracker?

  3. In the meantime, to avoid the conflicts, I think the best solution is for ome-common’s next release to exclude com.google.code.findbugs:annotations from its minio dependency declaration. That artifact is a strict subset of com.google.code.findbugs:jsr305, so I think it will not cause any problems, although of course should be tested to ensure everything still works.

  4. To fix the issue for pom-scijava with ome-common 6.0.0, I have added that exclusion beneath the ome-common dependency management block. The enforcer then passes on the latest Fiji master branch with the latest pom-scijava including that exclusion. I will release pom-scijava 26.0.0 including that workaround. Once a new ome-common exists with non-overlapping dependencies and has propagated to pom-scijava, the exclusion can be removed again.


Thank you very much for the heads-up Curtis, especially for the specific proposal. We’ll look at getting a fix into ome-common’s POM accordingly.