Maybe add a "netcdfExt" to uber-jars

[rschmunk]

Whenever I download a fresh netcdf-Java code archive, the first thing I have to do is modify the build.gradle.kts file in the uber-jars directory to specify compiling more code into the output jar so that additional dataset types can be opened. I am wondering if it might make sense and be useful to others to add an additional output jar to that configuration file, perhaps calling it netcdfExt.jar.

I just hacked my local copy of the latest 5.10 snapshot to do this, and it worked great. But unless the build.gradle.kts included in the source download includes those changes, then I again, I have to hack the file every time I update.

Good idea? Bad idea? Meh?

What I'm creating is

  // netcdfExt specific
  netcdfExt(project(":netcdf4"))
  netcdfExt(project(":cdm-s3"))
  netcdfExt(project(":cdm-zarr"))
  netcdfExt(project(":libaec-native"))
  netcdfExt(project(":libblosc2-native"))

[lesserwhirls]

I like this idea in general. It looks like the proposed netcdfExt jar would be the current netcdfAll jar + zarr and s3 related things. Arguably, netcdfAll should include those as well to be, uhhh, "all" of the things. If we did that, netcdfAll.jar would jump from 23 MB to 40 MB (thanks in large part to the AWS SDK and friends). In the past, some users of netcdfAll would get upset when the jar would increase by even a megabyte...in 2026? I don't know. I'd be in favor of leaning into the "all" spirit in netcdfAll.jar and letting it increase in size.

What do others think? Is anyone using netcdfAll that would NOT want these extra things?

[rschmunk]

I'm one of the people who used to freak out about app size, but that was a decade ago.

Things blew up when I decided to add support for Zarr or S3, I can't remember which at the moment. (Although Zarr seems the likely culprit.)

FWIW, the netcdefExt.jar in my devo lib folder is 42 MB.

At one point I was also looking at importing AWS jars, but the use case being so absolutely tiny and the jar bloat being so freaking huge, hah. Also, hah. No way.

[rschmunk]

Also, TBH, for the use cases I have heard from users, inclusion of Zarr and S3 seem less needed than including libaec and libblosc2.

Zarr inclusion could be much more useful if code were updated to handle Zarr v3.