Some 5.6.0 questions #1370
-
Im trying to work with the 5.6.0 release and have run into a couple things. Nothing I'd call a bug yet; they may just be me doing something wrong. The size of Also, does the gradle build process use a different, more efficient zip compression tool to create the final jar file? In order to get my app to notarize for use on a Mac, I have found that I have to unjar the netcdfAll build and then re-jar it, which I do by just calling jar from the command-line. Otherwise, the Apple notarization tool complains that some x86_64 native code in the build is not signed. However, the re-jarred library jumps in size, almost double what it was before. Note, this is not new to 5.6.0. Finally, although the jdom2 classes appears to be in the netcdfAll build, my app is complaining that |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
The netcdfAll-5.6.0.jar I see on our server is 20.9 MB and 21.9 MB when downloaded from our downloads page... so you're seeing 30MB before re-jarring and then almost 60MB after? Gradle uses the deflate (zip) algorithm to create the jars, my guess is you have a different deflate level set, but I can't for the life of me find what the default for gradle is. Skipping ahead to your jdom2 issue: we upgraded the version of the jdom library we use due to security issues, though that would have been present in the latest snapshot as well... |
Beta Was this translation helpful? Give feedback.
-
@haileyajohnson, If I do a And... I just found a serious flaw in my build-unjar-rejar script on this particular machine which is the source of the mega-bloat. Fixing that, I find that the new jar only goes up maybe 2% in size rather than doubling. And... third times a charm, my fault again. My app is now seeing the |
Beta Was this translation helpful? Give feedback.
@haileyajohnson, If I do a
./gradlew builtNetcdfall
without the S3 or Zarr code, then I get a 20.9 MB jar. Which okay, I just discovered that the 5.5.4 snapshot I have on this particular machine was not currently configured to include those modules when building. Further investigation reveals that the S3 module is responsible for about 75-80% of the size jump I was seeing and the Zarr module the rest.And... I just found a serious flaw in my build-unjar-rejar script on this particular machine which is the source of the mega-bloat. Fixing that, I find that the new jar only goes up maybe 2% in size rather than doubling.
And... third times a charm, my fault again. My app is now seeing the
XM…