Update jsvg to 2.1.0 in org.eclipse.swt.svg

[merks]

Update jsvg to 2.1.0 in org.eclipse.swt.svg

• Add class org.eclipse.swt.svg.logging.JVSGLoggerLogManager to
  implement the new logging service required by jsvg 2.1.0.
  • Simply print to System.err.
  • Only print ERROR level.
  • Support system property org.eclipse.swt.svg.logging to support other
    levels.
• Update the lower bounds to 2.1.0 because that provides the export of
  the com.github.weisj.jsvg.logging package which is needed for
  JVSGLoggerLogManager.
• Add /org.eclipse.swt.svg/resources/META-INF/services/com.github.weisj.jsvg.logging.LogManager
  which declares the org.eclipse.swt.svg.logging.JVSGLoggerLogManager
  service.
• Add Provide-Capability declarations for the service.
• Ensure that org.eclipse.swt.svg.JSVGRasterizer.SVG_LOADER is
  initialized while the context class loader references the bundle class
  loader of org.eclipse.swt.svg because the services are loaded using
  plain old Java which requires the service to be on the classpath.
• Do not export the org.eclipse.swt.svg.logging package because it's not
  needed outside of the fragment.

[merks]

I've tested that JVSGLoggerLogManager is used both in an OSGi runtime

And running stand alone:

But, the service is not in the bin folder so one needs to add the folder that contains the service declaration to the classpath:

In the end though, no service is needed because a default will be created in the absence of a service.

[merks]

I see that something needs to happen for the updated *.target to be available for use here.

[github-actions]

Test Results

  182 files  ±0    182 suites  ±0   26m 16s ⏱️ +16s
4 723 tests ±0  4 700 ✅ ±0   23 💤 ±0  0 ❌ ±0 
6 812 runs  ±0  6 649 ✅ ±0  163 💤 ±0  0 ❌ ±0 

Results for commit 39db096. ± Comparison against base commit 65f43d4.

♻️ This comment has been updated with latest results.

[merks]

I kicked https://ci.eclipse.org/releng/job/Builds/job/I-build-4.40/97/ so we can try to rebuild this PR after that's done.

[merks]

@HeikoKlare

FYI, I force pushed the change to move the service declaration to resources. I'll go out for a walk very soon.

[HeikoKlare]

Thank you for this adaptaiton, @merks. I've tested locally within products using OSGi and in standalone snippets, and it all works fine.

But, the service is not in the bin folder so one needs to add the folder that contains the service declaration to the classpath:

You have already adapted this behavior, Ed, just some additional background information:
we had the same issue with the SVGRasterizer service, which was solved by placing the service file in the resources/META-INF folder instead of the META-INF.

Regarding the logging: I wonder if we should simplify this. We do not use a logging API in SWT (but only System.err), so maybe we should not do that for the SVG extension either. What about just printing actual errors reported by JSVG via Sytem.err and prefixed with JSVGRasterizer.
We may think of a system propery that consumers can set to enable warnings as well, but everything with a log level below that will unlikely be of interest. Since it's only about warnings, one might also consider dealing with logs of level warnings and below as some kind of strict checks, for which we could use the existing StrictChecks.runIfStrictChecksEnabled().

[HeikoKlare]

I've tested this again and it works perfectly fine for me (both in OSGi and standalone use). I just had some issues using the system property for configuring logging, so there a minor proposal for improving its handling.

[HeikoKlare]

This is not very robust. Using a string does not exactly (including capitalization) match one of the existing logger levels results in no SVG being rendered. You will nothing very quickly 😆 but maybe we could be more resilient and in case the Logger.Level.valueOf(...) log some error stating that the set log level is unsupported and then make the log level default to error?

[merks]

Yes it's true. As we discussed, I'll push this through now so I can clean up the target platform before the nightly build and then you can improve this aspect at your leisure. You're right that in invalid value is kind of swallowed without good feedback.