Released builds produce no logs due to app image bundling multiple SLF4J

mattjala

The jpackage app image ships both `slf4j-nop` and `slf4j-simple`. SLF4J picks one arbitrarily, and in practice it picks NOP, so a released HDFView writes no log output. At present, `HDFView/lib/app` contains five SLF4J jars, including two versions of the API and two of `slf4j-simple`: ``` slf4j-api-2.0.16.jar slf4j-api-2.0.17.jar slf4j-nop-2.0.16.jar slf4j-simple-2.0.16.jar slf4j-simple-2.0.17.jar ``` There are two reasons for this duplication. First, `hdfview/pom.xml` declares both providers at runtime scope, `slf4j-nop` at line 36 and `slf4j-simple` at line 43. Both land in `target/lib` and then in the app image. Secondly, the duplicate 2.0.16 copies come from the jpackage input step that copies the HDF4 install directory wholesale, as that directory has its own SLF4J jars. We should fix this by picking one provider and shipping only that one, probably `slf4j-simple`, and then narrowing the jpackage copy step to avoid copying absolutely everything from the HDF4 install directory. Setting `-Dslf4j.provider=` in the launcher's java-options would force the desired choice, but leave the underlying duplication of shipping jars.

jhendersonHDF

This is not a bug (other than having two separate versions of the `-api` and `-simple` jars likely being unintentional), this is intentional by the original design at least and HDFView has always been shipped in a manner such that release versions don't produce logs by default. Before switching to the bundled application approach, HDFView was usually launched by a shell/batch script which contained a command invocation using the `-nop` jar; if someone wanted to enable logging they had to switch it to the `-simple` jar. https://github.com/HDFGroup/hdfview/blob/master/docs/USING_logging.txt