
- The
formats-gpl project depends on ch.systems.cisd:jhdf5:14.12.0. This is an unshaded uberjar with commons-lang and commons-io dependencies lumped in.
- The
bigdataviewer-core project depends on cisd:jhdf5:14.12.6. This does not include commons-lang and commons-io, but rather declares them properly as dependencies. But unfortunately uses a less proper groupId.
Two problems here:
-
The different groupIds mean that Maven's normal dependency version resolution does not take place, resulting in duplicate classes on the classpath when both of these dependencies are used. The fix will be to reconcile these two different packagings, such that all SciJava components in the collection depend on the same GA.
-
The ch.systems.cisd:jhdf5:14.12.0 unshaded uberjar results in duplicate classes with anything else depending on commons-lang and/or commons-io. The fix will be for formats-gpl to start depending on a non-uberjar JHDF5 artifact.
This issue is a blocker to new pom-scijava releases.
Proposed way forward: I create a new ch.systems.cisd:jhdf5:14.12.6 incorporating the best aspects of both artifacts above—separated commons dependencies, and correct groupId—and we deploy this artifact to the OME Maven repository (?). Then we update both formats-gpl and bigdataviewer-core to depend on it.
CC @joshmoore @sbesson @tpietzsch
formats-gplproject depends onch.systems.cisd:jhdf5:14.12.0. This is an unshaded uberjar with commons-lang and commons-io dependencies lumped in.bigdataviewer-coreproject depends oncisd:jhdf5:14.12.6. This does not includecommons-langandcommons-io, but rather declares them properly as dependencies. But unfortunately uses a less proper groupId.Two problems here:
The different groupIds mean that Maven's normal dependency version resolution does not take place, resulting in duplicate classes on the classpath when both of these dependencies are used. The fix will be to reconcile these two different packagings, such that all SciJava components in the collection depend on the same GA.
The
ch.systems.cisd:jhdf5:14.12.0unshaded uberjar results in duplicate classes with anything else depending oncommons-langand/orcommons-io. The fix will be forformats-gplto start depending on a non-uberjar JHDF5 artifact.This issue is a blocker to new pom-scijava releases.
Proposed way forward: I create a new
ch.systems.cisd:jhdf5:14.12.6incorporating the best aspects of both artifacts above—separated commons dependencies, and correct groupId—and we deploy this artifact to the OME Maven repository (?). Then we update bothformats-gplandbigdataviewer-coreto depend on it.CC @joshmoore @sbesson @tpietzsch