use upstream nrjavaserial 3.15.0 on runtime #761

maggu2810 · 2019-04-27T13:22:37Z

Fixes: #750

I see two possible fixes for #750:

use the upstream library all the time and drop the OH specific release of nrjavaserial
state that the OH nrjavaserial provides the specific capability (openhab.tp;feature=serial;impl=rxtx)

I don't know what's the difference between 3.15.0.OH2 of openHAB's nrjavaserial and 3.15.0 of the upstream one.
The nrjavaserial repository of openHAB does not contain any tag or commit that tells me anything about that.

So, let's wait for a reply to #750 (comment)

At the moment I switch to the upstream one in this PR, but we can also remain at the OH spefic one, if working with upstream of nrjavaserial is not possible.

Fixes: #750 Signed-off-by: Markus Rathgeb <[email protected]>

Signed-off-by: Markus Rathgeb <[email protected]>

maggu2810 · 2019-04-27T18:57:48Z

I updated this PR to provide two nrjavaserial features:

the upstream nrjavaserial that is using liblockdev
the openHAB modified one that does not use liblockdev

The openhab-transport-serial feature uses the openHAB modified nrjavaserial

maggu2810 · 2019-04-27T20:23:29Z

karaf@root()> feature:install openhab-transport-serial

This results into this bundles being installed:

241 │ Active   │  80 │ 3.15.0.OH2             │ mvn:org.openhab/nrjavaserial/3.15.0.OH2
242 │ Active   │  80 │ 2.5.0.201904271903     │ mvn:org.openhab.core.bundles/org.openhab.core.config.discovery.usbserial/2.5.0-SNAPSHOT
243 │ Active   │  80 │ 2.5.0.201904271903     │ mvn:org.openhab.core.bundles/org.openhab.core.config.discovery.usbserial.linuxsysfs/2.5.0-SNAPSHOT
244 │ Active   │  80 │ 2.5.0.201904271904     │ mvn:org.openhab.core.bundles/org.openhab.core.config.serial/2.5.0-SNAPSHOT
245 │ Active   │  80 │ 2.5.0.201904271901     │ mvn:org.openhab.core.bundles/org.openhab.core.io.transport.serial/2.5.0-SNAPSHOT
246 │ Active   │  80 │ 2.5.0.201904271903     │ mvn:org.openhab.core.bundles/org.openhab.core.io.transport.serial.rxtx/2.5.0-SNAPSHOT
247 │ Active   │  80 │ 2.5.0.201904271903     │ mvn:org.openhab.core.bundles/org.openhab.core.io.transport.serial.rxtx.rfc2217/2.5.0-SNAPSHOT

maggu2810 · 2019-04-27T20:24:04Z

@openhab-5iver Would you like to review that change?

5iver · 2019-04-27T21:29:08Z

Would you like to review that change?

I have to run out (actually helping a friend setup OH!), and will be working on helper libraries tomorrow. I can take a look later in the week and do some testing!

maggu2810

To simplify the review process I added comments to the changes to explain why it has been done.

maggu2810 · 2019-04-28T11:49:05Z

bom/runtime/pom.xml

@@ -446,7 +446,7 @@
    <dependency>
      <groupId>com.neuronrobotics</groupId>
      <artifactId>nrjavaserial</artifactId>
-      <version>3.14.0</version>
+      <version>3.15.0</version>


That's just for testing (runtime POM is used in itests and for the Bnd based demo applications). I don't see any need to use a non upstream implementation there (we can consider to change it if someone needs it because he develop on an arm64 machine).

maggu2810 · 2019-04-28T11:50:31Z

features/karaf/openhab-core/pom.xml

@@ -17,7 +17,6 @@
  <properties>
    <jetty.version>9.4.12.v20180830</jetty.version>
    <jna.version>4.5.2</jna.version>
-    <nrjavaserial.version>3.15.0.OH2</nrjavaserial.version>


That property has not been necessary at all, as it is used at one place -- in the feature.
There is no "win" to define it here and reference in the feature.
We can define it in the feature.

Now the bundle declaration in the feature has been moved at all to another feature repository.

maggu2810 · 2019-04-28T11:51:19Z

features/karaf/openhab-core/src/main/feature/feature.xml

@@ -609,7 +609,7 @@
  </feature>

  <feature name="openhab-transport-serial" description="Serial Transport" version="${project.version}">
-    <bundle>mvn:org.openhab/nrjavaserial/${nrjavaserial.version}</bundle>
+    <feature>openhab.tp-serial-rxtx-noliblockdev</feature>


Don't inject external dependencies but use a "target platform feature".
We do not use dependency="true" here because we want to force the usage of that specific serial implementation.

maggu2810 · 2019-04-28T11:51:49Z

features/karaf/openhab-tp/src/main/feature/feature.xml

@@ -154,7 +154,12 @@

  <feature name="openhab.tp-serial-rxtx" version="${project.version}">
    <capability>openhab.tp;feature=serial;impl=rxtx</capability>
-    <bundle>mvn:com.neuronrobotics/nrjavaserial/3.14.0</bundle>
+    <bundle>mvn:com.neuronrobotics/nrjavaserial/3.15.0</bundle>


Bump upstream nrjavaserial from 3.14.0 to 3.15.0.

maggu2810 · 2019-04-28T11:52:44Z

features/karaf/openhab-tp/src/main/feature/feature.xml

+    <bundle>mvn:com.neuronrobotics/nrjavaserial/3.15.0</bundle>
+  </feature>
+
+  <feature name="openhab.tp-serial-rxtx-noliblockdev" version="${project.version}">


Add a separate feature for the openHAB "no liblockdev" nrjavaserial.
The "important" point here is, that we also provide the specific capability, so our features know about the provided serial implementation.

kaikreuzer · 2019-04-28T15:01:04Z

With the input from @wborn, shouldn't we simply ONLY use 3.15.0.OH2 as it is a kind of pre-release of the official 3.16.0 and we know that it solves a few issues that otherwise occur?

maggu2810 · 2019-04-28T16:59:14Z

Hm, I am using nrjavaserial 3.14.0 on several systems (arm 32bit and x86_64) running Debian Stretch (9). So it works with liblockdev. If there is no functionality lost I can think about switching to the OH released one.
But if my reading has been correct there is no PR provided to upstream or any comment that liblockdev will be removed in the next version. But I have to admit that I did not read the whole referenced issue from the beginning to the end.

Signed-off-by: Markus Rathgeb <[email protected]>

maggu2810 · 2019-04-28T18:27:11Z

@kaikreuzer I changed to provide only one nrjavaserial implementation (the OH one). I am looking forward to get the downstream changes merged upstream and to use that one after the next release.

5iver

@maggu2810, when I first looked at this, I incorrectly thought that there was a jar I could build and test. What I ended up doing was shutting down OH, modified the distro-2.5.0-SNAPSHOT-features.xml file as in the two feature.xml files, cleared cache and tmp, and restarted OH. Everything seemed to come up without nrjavaserial 3.14.0, but zwave is still having the same issue where it will not startup with OH and requires restarting the binding to get it running. Zigbee (still using the old serial transport) came up fine.

So, I either made a mess of things, or showed that at least a portion of this PR will work, but does not fix the zwave issue.

Oh... this got merged!? Teaches me not to leave tabs open!

5iver · 2019-04-29T12:47:10Z

features/karaf/openhab-tp/src/main/feature/feature.xml

@@ -154,7 +154,12 @@

  <feature name="openhab.tp-serial-rxtx" version="${project.version}">
    <capability>openhab.tp;feature=serial;impl=rxtx</capability>
-    <bundle>mvn:com.neuronrobotics/nrjavaserial/3.14.0</bundle>
+


Extra line?

I used that empty line to separate the commented stuff from other lines.

5iver · 2019-04-30T06:28:49Z

features/karaf/openhab-tp/src/main/feature/feature.xml

+    <!-- See: https://github.com/openhab/openhab-core/pull/761 -->
+    <!-- See: https://github.com/openhab/openhab-core/issues/750 -->
+    <!-- <bundle>mvn:com.neuronrobotics/nrjavaserial/3.15.0</bundle> -->
+    <bundle>mvn:org.openhab/nrjavaserial/3.15.0.OH2</bundle>


Should this be statically called, or should it be...

<bundle>mvn:org.openhab/nrjavaserial/${nrjavaserial.version}</bundle>

... like it was in the openhab-transport-serial?

The version should be statically (I tried to already comment this in a self made review of my own changes).

maggu2810 · 2019-04-30T06:51:37Z

@openhab-5iver I did not have a look at some specific binding problem.
I just tried to solve "[nrjavaserial] Multiple versions".

After there is only one version the binding author can perhaps have a look at.

When debugging openHAB in Eclipse I ran into serial port locking issues again on Ubuntu 18.04.2. We resolved these in the distro by using 3.15.0.OH2 which doesn't use licklockdev. Errors similar to the one below may show after stopping/restarting openHAB when using serial ports on certain distros: RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyUSB0: File exists. It is mine testRead() Lock file failed See also: openhab#761 Signed-off-by: Wouter Born <[email protected]>

When debugging openHAB in Eclipse I ran into serial port locking issues again on Ubuntu 18.04.2. We resolved these in the distro by using 3.15.0.OH2 which doesn't use liblockdev. Errors similar to the one below may show after stopping/restarting openHAB when using serial ports on certain distros: RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyUSB0: File exists. It is mine testRead() Lock file failed See also: openhab#761 Signed-off-by: Wouter Born <[email protected]>

When debugging openHAB in Eclipse I ran into serial port locking issues again on Ubuntu 18.04.2. We resolved these in the distro by using 3.15.0.OH2 which doesn't use liblockdev. Errors similar to the one below may show after stopping/restarting openHAB when using serial ports on certain distros: RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyUSB0: File exists. It is mine testRead() Lock file failed See also: #761 Signed-off-by: Wouter Born <[email protected]>

* add nrjavaserial without liblockdev * use only one feature for a nrjavaserial implementation Fixes: openhab#750 Signed-off-by: Markus Rathgeb <[email protected]> GitOrigin-RevId: d2c7db6

When debugging openHAB in Eclipse I ran into serial port locking issues again on Ubuntu 18.04.2. We resolved these in the distro by using 3.15.0.OH2 which doesn't use liblockdev. Errors similar to the one below may show after stopping/restarting openHAB when using serial ports on certain distros: RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyUSB0: File exists. It is mine testRead() Lock file failed See also: openhab#761 Signed-off-by: Wouter Born <[email protected]> GitOrigin-RevId: 060530a

maggu2810 added 2 commits April 27, 2019 15:18

use upstream nrjavaserial 3.15.0 on runtime

eeef063

Fixes: #750 Signed-off-by: Markus Rathgeb <[email protected]>

add nrjavaserial without liblockdev

3e5b9fc

Signed-off-by: Markus Rathgeb <[email protected]>

maggu2810 commented Apr 28, 2019

View reviewed changes

cweitkamp requested a review from wborn April 28, 2019 14:30

use only one feature for a nrjavaserial implementation

47cfd98

Signed-off-by: Markus Rathgeb <[email protected]>

kaikreuzer approved these changes Apr 29, 2019

View reviewed changes

kaikreuzer merged commit d2c7db6 into openhab:master Apr 29, 2019

maggu2810 deleted the nrjavaserial branch April 29, 2019 21:18

5iver suggested changes Apr 30, 2019

View reviewed changes

wborn mentioned this pull request May 25, 2019

Use nrjavaserial 3.15.0.OH2 in BOMs #833

Merged

mhilbush mentioned this pull request Jun 19, 2019

don't use safe caller for event delegation to subscribers #861

Merged

wborn added this to the 2.5 milestone Jul 30, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

use upstream nrjavaserial 3.15.0 on runtime #761

use upstream nrjavaserial 3.15.0 on runtime #761

maggu2810 commented Apr 27, 2019

maggu2810 commented Apr 27, 2019

maggu2810 commented Apr 27, 2019

maggu2810 commented Apr 27, 2019

5iver commented Apr 27, 2019

maggu2810 left a comment

maggu2810 Apr 28, 2019 •

edited

Loading

maggu2810 Apr 28, 2019

maggu2810 Apr 28, 2019

maggu2810 Apr 28, 2019

maggu2810 Apr 28, 2019

kaikreuzer commented Apr 28, 2019

maggu2810 commented Apr 28, 2019

maggu2810 commented Apr 28, 2019

5iver left a comment •

edited

Loading

5iver Apr 29, 2019

maggu2810 Apr 30, 2019

5iver Apr 30, 2019

maggu2810 Apr 30, 2019

maggu2810 commented Apr 30, 2019

use upstream nrjavaserial 3.15.0 on runtime #761

use upstream nrjavaserial 3.15.0 on runtime #761

Conversation

maggu2810 commented Apr 27, 2019

maggu2810 commented Apr 27, 2019

maggu2810 commented Apr 27, 2019

maggu2810 commented Apr 27, 2019

5iver commented Apr 27, 2019

maggu2810 left a comment

Choose a reason for hiding this comment

maggu2810 Apr 28, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaikreuzer commented Apr 28, 2019

maggu2810 commented Apr 28, 2019

maggu2810 commented Apr 28, 2019

5iver left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maggu2810 commented Apr 30, 2019

maggu2810 Apr 28, 2019 •

edited

Loading

5iver left a comment •

edited

Loading