Extract ome module

[konstibob]

Restructured zarr-java into two Maven submodules, zarr-java-core and
zarr-java-ome, making OME-Zarr an optional import.

Also adds Jupyter notebooks under notebooks/ for exploring the library
locally without having to publish changes to Maven Central. Run with
./notebooks/start.sh.

Naming convention change: the OME package moved from
dev.zarr.zarrjava.experimental.ome to dev.zarr.omezarr.

Updated USERGUIDE.md and USERGUIDE-OME-ZARR.md for the new module layout,
package names, and dependency coordinates.

[normanrz]

Very high-level feedback. I would rename the modules:

• zarr-java-core -> zarr-java
• zarr-java-ome -> omezarr-java

I don't think the notebooks need to be in the repository. Please remove.

@sbesson @melissalinkert Do you have some feedback on splitting up into 2 modules/jars?

[melissalinkert]

I don't have a problem in general with splitting into separate submodules, though it would be useful to know why this is necessary.

I'm not yet using dev.zarr.zarrjava.experimental.ome, so the package rename to dev.zarr.omezarr isn't breaking right now (but it might be for anyone else who is using zarr-java). I would strongly suggest against any further package renames though.

I think my main concern is with artifact IDs. All of the pom.xml suggest that we can continue to use dev.zarr:zarr-java:<version> to get both modules (and that is my preference), but the user guide only mentions using the individual artifact IDs for the new modules. Since that would be a breaking change for everyone who uses zarr-java, it would be good to clarify what is expected for the zarr-java artifact ID.

[normanrz]

@joshmoore Can you please elaborate the motivation for splitting up the jars?
Personally, I would also be fine with keeping everything in one jar.

[joshmoore]

I'm running short on time so a immediate few thoughts:

• From the OME perspective
  • I don't particularly want to be blocked on a release by Zarr-level things
  • (which goes to say, I see there as being more than one version number here)
• From the Zarr perspective:
  • I don't immediately understand why this is here.
  • However, if this is something that we want to do/explain, it should be clear how others join.

In terms of existing models, I was largely thinking about https://github.com/zarrs/ome_zarr_metadata . That being said, I think there's definitely more than one way to do it, I would just make it feel intentionally to members of both communities.

[normanrz]

Thanks @joshmoore. I think this comes down to whether it confuses people that the OME-Zarr metadata is in the zarr-java artifact or not. From the pov of an OME-Zarr implementation it is of course more convenient to have it in a single artifact; I got that feedback a couple of times now.

I don't particularly want to be blocked on a release by Zarr-level things

I don't think the release numbers of zarr-java have to correlate with either the zarr format nor OME-Zarr versions. Why would there be any blocking?

I don't immediately understand why this is here.

Fair enough. But it doesn't hurt unless it requires additional dependencies.

However, if this is something that we want to do/explain, it should be clear how others join.

Maybe it should move under dev.zarr.conventions.ome? Someone else could open a PR to add dev.zarr.conventions.geo when it exists.

[sbesson]

Echoing @melissalinkert's comments above, my biggest piece of feedback is "let's not rename things (package, artifacts....) unless we have identified a clear rationale and well-identified benefit for users". The zarr-java -> zarr-java-core in particular is not something I find useful.

The biggest point of discussion started by this contribution is whether zarr-java should only be focused about the low-level Zarr implementation or also include an OME-Zarr implementation. My understanding is that OME-Zarr is not a primary citizen of this library with the OME-Zarr support introduced in an experimental package and OME-Zarr being absent from the primary README.

The most essential requirement from our side is to ensure we can maintain and rely upon a robust reference Zarr library for the JVM, as was originally discussed during the [2022 OME community meeting] (https://www.openmicroscopy.org/events/ome-community-meeting-2022/). When it comes to adding OME-Zarr support, using either one artifact with multiple packages or having multiple artifacts are both fine strategies for which we are working precedents. If we decide to use multiple artifacts, I have a preference for splitting the OME Zarr implementation in a separate downstream repository and versioning it separately instead of using a multi-module project.