Cherry-pick from 2.8.1-experimental

[tresf]

@bmhm I think you're the best candidate for this, but there are some decisions that were made in the 2.8.1-experimental branch that may be useful for this project. Some are duplicates of open bug reports (such as code formatter) but I wanted a proper review of this experimental branch before purging it.

[bmarwell]

Ok, this is what I picked up from the diff (thanks for directly linking the compare view btw!):

• Maven sources and javadoc jars could be generated, at least in the package profile. Generate sources and javadoc jar in release profile #38
• formatter-plugin (instead of checkstyle), which will format code upon compilation. Intersting. See this interesting blog post about it. You can find the plugin here: https://github.com/google/google-java-format. We should track it here: Create a checkstyle config for java #12.
• -Xlint:all which is pretty much like -Wall in C. Yes, that’s a good idea. The checks are described in this blog post on javaworld, and in my opinion, all of them make sense. Tracked in Enable javac compiler warnings #34.
• maven-bundle-plugin and maven-scr-plugin: Those are for OSGi modules. OSGi is much more adopted than java modules and would be a nice feature to ship dependencies in the same jar. But I have never used OSGi bundles, so I cannot really help here. Consider OSGi artifacts using apache felix maven plugin #39
• File renaming from src/<language> to src/main/<language> -- that's what I have proposed, too. But we agreed on waiting for patches to be included before we make that transition.
• SerialNativeAccess.java is pretty much what native-lib-loader does. We could pick out parts like this line (v2.8.0...java-native:2.8.1-archive#diff-77f0faf141ca0a69b33644e479631d5dR89) to implement armsf or armhf if needed. (issue filed: Differentiate between ARM hardware floating point and software #35)
• package renamed from jssc to org.scream3r.jssc. We also need to do this in the near future, but to io.github.javanative.jssc. => Project rename proposal #5
• Tests: Some do have value. I was thinking of similar things.

That about wraps it up. I wish we could have @vogt31337 here to help us implement that maven-osgi part (Apache Felix maven-bundle-plugin).

[tresf]

@bmhm thanks. So what I'd like to do is find a way to purge this experimental branch from our code. Can we open relevant issues, copy code snippet, etc or do you feel it's best to keep it around for a while?

[bmarwell]

Let's just tick the box for every issue we opened to keep track of them individually.

[tresf]

SerialNativeAccess.java is pretty much what native-lib-loader does. We could pick out parts like this line (v2.8.0...java-native:2.8.1-archivediff-77f0faf141ca0a69b33644e479631d5dR89) to implement armsf or armhf if needed.

This code already exists in the source tree under a different file (not specific to 2.8.1 branch) https://github.com/java-native/jssc/blob/v2.8.0/src/java/jssc/SerialNativeInterface.java#L118-L135.

Since we don't have a bug report for it, I'll create one and tick the box.

File renaming from src/ to src/main/ -- that's what I have proposed, too. But we agreed on waiting for patches to be included before we make that transition.

Can you check it off then, or is this not yet explained in a bug report?

[tresf]

Copied the unit tests into #37 @bmhm just need checkboxes 1 and 4 ticked, then we can purge off this branch.

[tresf]

All items are checked off. Closing and purging 2.8.1 branch.