| Hi Marco,
I am not sure about this. javax.comm was defined using the JCP process.
"Java communications API was initially released in 1997, prior to the Java Community Process, was 'grandfathered in' to the JCP ( http://www.jcp.org) without having an associated JSR (Java Specification Request)." Hence I have no clue where it really originates from...
We to not plan to maintain it beside very minor changes like the serial port names support.
You mean manually maintaining the static list of port names. Or do you plan to make a change to have some RXTX-like property file instead? If the dkcomm implementation does not work on some platform - do you have experience with using RXTX as a javax.comm implementation as an alternative? Does this work in general?
After the target platform build you can find the bundle under the following path.
Yes, this is what I did already. But for making use of it within Eclipse SmartHome (or Scada or other projects), it would be very useful to have it available in a p2 repository (or the Eclipse Maven repo), so that it can be easily referenced and packaged during the build. I would not want to copy the source code (nor the binary) to my repo for this. It seems as it this is a perfect candidate for an Orbit-like shared repo for Eclipse IoT. As it still might take a while until we have established such a shared repo - would it mean much effort for you to deploy this jar file to the Eclipse Maven repo during your build? Or is there any IP/CQ reason why this cannot be done (it is clear that I would still file a CQ for reusing it).
Regards, Kai
Hello Kai.
Hi Marco,
Thanks a lot for your feedback!
So if here at Eclipse the only option for serial access is javax.comm + dkcomm, I wonder about the status of it.
A few questions about this:
I am not sure about this. javax.comm was defined using the JCP process. I am wondering whether the initial reference came from IBM.
2. So the „soda“ project is archived and thus inactive and you took over the sources? Do you plan to maintain it in some way, e.g. fixing bugs that you find? Having to recompile things for uncommon serial port names is pretty annoying :-(
We pulled in the sources and validated the functionality on the open hardware platforms like Rasp and BBB. We to not plan to maintain it beside very minor changes like the serial port names support. 3. Is the dkcomm bundle made available by Kura as a jar on some p2 or Maven repo? Or what would be the best way to get hold of javax.comm for the EnOcean base driver to compile against?
We do not publish the bundle in maven or p2 but the bundle is available in the Kura target platform. After the target platform build you can find the bundle under the following path. The native libraries are included in the same bundle. kura/kura/target-definition/common/repository/plugins/org.eclipse.soda.dk.comm_1.2.1.jar
Regards. -Marco
Best regards, Kai
Hello Kai.
For Kura, we are packing org.eclipse.soda.dk.comm as the default implementation for javax.comm. As you pointed out, our choice on org.eclipse.soda.dk.comm was driven by the fact that RxTx is GPL licensed.
In our tests, we found javax.comm fairly stable but we did encounter few glitches. - We experienced a crash of the dkcomm native library when interfacing with 3g modems connected via USB. The crash was random and not easily reproducible. - In long running tests, we experienced a memory leak from the native library. - Support for non common serial port names (e.g. ttyACM, …) requires a code change in the native library. RxTx has an external properties file.
Both issues were not experienced when using the javax.comm implementation to RxTx. Unfortunately, we did not go very far in debugging the dkcomm implementation.
The good news is that we found the two implementation to be quite compatible.
That’s what we know so far.
Regards. -Marco
All,
I think it is very nice to have one important home automation protocol implementation at Eclipse IoT this way. We will maintain it as a part of Eclipse SmartHome as it didn’t feel to be worth the overhead of an independent project.
There is just one concern that I still have before creating a CQ for the contribution: As EnOcean requires a USB dongle, the driver currently requires an RXTX bundle on the runtime. As RXTX is under LGPL, this is no option for Eclipse. What should I resort to? I see that Kura uses javax.comm as an API and org.eclipse.soda.dk.comm as an implementation. Is this the recommended way? Is this library stable and reliable? In this case I would probably have to ask Orange to change their code to use javax.comm instead of rxtx.
Any hints are welcome!
Thanks, Kai
_______________________________________________ iot-wg mailing list iot-wg@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/iot-wg
_______________________________________________ iot-wg mailing list iot-wg@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/iot-wg
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg
|
