Couple improvements

[dmitry-cherkas]

*patch for Arduino by Cristian Maglie (arduino/Arduino@f91670e)

• mark slf4j-api as provided, to prevent it from being packed into jar-with-dependencies (execution environment may have a different api version, which will result in conflicts)

[tresf]

@dmitry-cherkas thanks, I'm not a Maven expert and Ben has disassociated with the project. We need to bundle slf4j in our uber jar, will this affect that?

[dmitry-cherkas]

@tresf , yes, this will exclude slf4j from uber jar. My situation is the opposite, I had issues incorporating your uber jar into my IntelliJ plugin(https://plugins.jetbrains.com/plugin/8031-serial-port-monitor). NP, if that doesn't meet your use case - feel free to ignore this PR.

[tresf]

What if we make a build target that doesn't include it?

[tresf]

This response is two parts: 1. slf4j. 2. code fixes

slf4j

If we disclude slf4j from distribution, users grabbing the jar-with-dependencies will receive the following error trying to use the library:

Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
	at org.scijava.nativelib.BaseJniExtractor.<clinit>(BaseJniExtractor.java:58)
	at org.scijava.nativelib.NativeLoader.<clinit>(NativeLoader.java:100)
	at jssc.SerialNativeInterface.<clinit>(SerialNativeInterface.java:88)
	at TestClass.main(TestClass.java:5)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	... 4 more

Note, currently, mvn by default will build the jar without dependencies (so it will instead complain about missing nativelibloader, if trying to run as a standalone).

Since we intend to distribute a working standalone library we have a few options:

• Downstream projects don't use the version with dependencies at all, add in dependencies manually
  --OR--
• Pollyfill in slf4j compilation via some ugly class reflection (soft-failing or using System.out when it's not available)
  --OR--
• Accept this PR and we change our packaging steps

I really don't love any of the above options, but pragmatically speaking, slf4j is a dependency like nativelibloader so they should both be held to the same standard. For those reasons, I would encourage any projects bundling JSSC to maintain their own dependency versions.

code fixes

In addition to the mvn changes, there are some code changes around detecting serial ports. These changes shouldn't be ignored if the mvn changes aren't accepted and probably warrant their own discussion.

At a glance, it appears the POSIX port matching is being loosened, and I'd like to have some documented justification for those changes. Would it make sense to offer these in a separate PR?

For example, the port matching does this for macOS:

-               PORTNAMES_REGEXP = Pattern.compile("tty.(serial|usbserial|usbmodem).*");
+               PORTNAMES_REGEXP = Pattern.compile("(tty|cu)\\..*");

... and then later does this for Linux:

+               if (fileName.startsWith("ttyS")) {
...
+               }

Can we get a PR with these changes explained so that they aren't potentially lost with the mvn stuff?

[tresf]

I found the port change explanation, I've appended it to the PR description.

JSSC, on unix based systems like linux and MacOSX, when listing serial ports
tries to open each port to ensure its existence. While this check works well for
linux ports /dev/ttyS0..31, it leads to unexpected behaviors on MacOSX in
particular with USB-CDC virtual serial ports.

This patch disable the check and keep it enabled only for linux ttySxx ports.

This adds also tty.* and cu.* to the list of available serial ports on MacOSX.

Using a hypervisor I tested adding a "physical" port to macOS and can confirm that /dev/cu.* is the correct pattern, so I'd like to move forward with this PR. I assume that the ttyS pattern is never used on MacOS now?

[tresf]

Superceded by #97. We'll be merging this soon, thanks!