Repository navigation
Reconcile jhdf5 artifact usages #87
Description
- The
formats-gplproject depends onch.systems.cisd:jhdf5:14.12.0. This is an unshaded uberjar with commons-lang and commons-io dependencies lumped in. - The
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.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.
Activity
POM: update dependencies
sbesson commentedon Apr 5, 2019
Hi @ctrueden,
thank you very much for raising this issue publicly and the proposal to move forward. Quite timely, we are reviewing some of our dependencies for the next minor release of Bio-Formats.
The
jhdf5library was introduced by @sommerc and updated to its latest version in ome/bioformats#1753 i.e. four years ago. Since then we have not bumped it as there has been no real dataset drivers.The
cisd:jhdf5:14.12.6of the BDV matches the latest stable upstream release on the 14.12.x line. Immediately, what we can try on our end is testing the upgrade of this particular dependency to use the same JAR as the one declared bybigdataviewer-coreand verify it does no introduce any regression in readers or writers.ctrueden commentedon Apr 5, 2019
Thanks @sbesson. If you are willing to use the existing
cisd:jhdf5:14.12.6artifact, even though the groupId is less optimal, that is OK and would address the issues described here. Please let me know if testing uncovers any issues with it.sbesson commentedon Apr 24, 2019
Updating this thread with the latest status. Our CI and manual testing has not revealed any obvious issue so we are planning to switch to
cisd:jhdf5:14.12.6in our next minor release of Bio-Formats.We have cut a milestone release and pushed it to the development Bio-Formats update site. That way we can also get early feedback of any breakage. But at this stage I anticipate this should be fine. We can close the issue when the
formats-gplcomponent is bumped to6.1.0sbesson commentedon Jun 12, 2019
Closing as this should be solved since the release of Bio-Formats 6.1.0