Make junit only test and add module info

[bowbahdoe]

No description provided.

[C0urante]

Great catch, thanks so much!

[C0urante]

Hmmm... actually, there's one small snag here. I'm able to build and test with Java 12+ but when using Java 11, tests fail with an error:

java.io.IOException: Received fatal alert: handshake_failure
	at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
	at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
	at io.github.c0urante.joplin@0.2.0-SNAPSHOT/io.github.c0urante.joplin.HueEntertainmentClient.startEntertainment(HueEntertainmentClient.java:337)
	at io.github.c0urante.joplin@0.2.0-SNAPSHOT/io.github.c0urante.joplin.HueEntertainmentClient.initializeStream(HueEntertainmentClient.java:186)
	at io.github.c0urante.joplin@0.2.0-SNAPSHOT/io.github.c0urante.joplin.HueEntertainmentClientTest.testWhite(HueEntertainmentClientTest.java:62)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
	at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:185)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:171)
	at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681)
	at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636)
	at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454)
	at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433)
	at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:637)
	at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate$Reader.unwrapBuffer(SSLFlowDelegate.java:481)
	at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate$Reader.processData(SSLFlowDelegate.java:392)
	at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher.run(SSLFlowDelegate.java:264)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

Adding <useModulePath>false</useModulePath> to the configuration for the maven-surefire-plugin fixes this, but I'm not certain this is wise since I haven't verified yet whether the root cause is a bug with the project, a problem with my Java setup, just a quirk of the testing environment, or something else.

I've found https://bugs.openjdk.org/browse/JDK-8221674 which seems promising, but even after verifying that the jdk.crypto.ec.jmod file was present in the $JAVA_HOME/jmods directory for my Java 11 compiler, the issue persists.

@bowbahdoe if you have any insight on this, please let me know. Otherwise, I'll try to do some more digging later to see if this is worth worrying about. In the meantime, I'd be happy to merge the changes to the POM now and tackle adding a module-info.java file in a separate PR if you'd prefer.

Thanks again for your contribution, by the way!

[C0urante]

Okay, I've verified a few things:

1. The test failure is possibly due to missing cipher suites in the runtime environment. Running with debug output enabled using Java 12, it looks like the negotiated cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256; running with debug output enabled using Java 11, that cipher suite is not offered by the client when trying to contact the bridge's REST API.
2. Anecdotally, this does not break the client for downstream projects, even ones that use modules and/or Java 11. Verified this by building a local project that had its own module-info.java which required io.github.c0urante.joplin, and then running that project with Java 11 via mvn exec:java using a mainClass that began with the name of the module for the local project.

Given this, I'm inclined to merge and address test issues with Java 11 as a follow-up item.