| Kura in existent OSGi container ? [message #1721608] |
Thu, 28 January 2016 10:35  |
Eclipse User |
|
|
|
Hi,
I started to investigate Kura. I saw that existence of .deb package for Raspberry devices.
Is this package installing Equinox only or there are more things being set by scripts?
I'm asking because I already have an OSGi container installed into my devices and this container have a deployment package management service started.
would be possible to use Kura in such devices by installing the necessary bundles using a deployment service ?
thanks
|
|
|
|
| Re: Kura in existent OSGi container ? [message #1721801 is a reply to message #1721787] |
Sun, 31 January 2016 00:32  |
| Eclipse User |
|
|
|
I have successfully run Kura in an Apache Karaf container.
Cristiano, if you were to take the bundles that David mentioned and package them in a Deployment Package zip file, it should work. You will probably not want to repackage things like Equinox DS, Metatype, Event Admin, etc that probably already are installed and running in your container.
One thing that you may need to set too, but Dave can confirm, is the "kura.configuration" environment variable, that should point to a kura.propeties file similar to [1]
[1] https://github.com/eclipse/kura/blob/develop/kura/distrib/src/main/resources/raspberry-pi-2/kura.properties
[Updated on: Sun, 31 January 2016 00:33] by Moderator |
|
|
|
|
| Re: Kura in existent OSGi container ? [message #1751132 is a reply to message #1721935] |
Wed, 04 January 2017 13:42 |
| Eclipse User |
|
|
|
Christiano,
I think that sounds like the right approach to the problem and have worked with the Karaf 4 mechanisms for using profiles to install requisite dependencies in zip implementations.
This is obviously going to depend on using OSGi services to abstract away details of the implementation for GPIO, I2C, SPI and whatever other devices might become supported. Configuration will change from board to board, obviously, but as a developer I won't have to change my code implementation in order to use it.
There are already interfaces that standardize the various board level interfaces. But in code samples I'm seeing direct access to things like DeviceManager which break portability and requisite separation of concerns in code (as opposed to configuration).
Eventually the OSGi service abstractions will have to be available all the way up the stack and require interfaces for sensor/actuators where the various pin/device service interfaces can be injected without the sensor/actuator controller needing to be aware of the underlying board or implementation details. The services have to be exported and injected into consuming bundles, they can't be pulled from static factories that are about lower level concerns.
Those sorts of sensor/actuator APIs and libraries may or may not be appropriate in the Kura project depending on the mission statement and vision.
But there are at least three levels of abstraction that I think will be important here - board level devices exported via OSGi services and service factories. Sensor/actuator libraries that reference injected board level OSGi services, and application level that use OSGi sensor/actuator services APIs with implementation bundles developed for various sensors and actuators.
It basically boils down to uses like the following. If I inject a MotorControlService into my application bundle I don't care about how the motor control works - PAM, PWM, or PPM nor which pins or devices that controller uses. I simply want to use the MotorControllerService interface. If I switch to a different motor for performance or cost reasons, I don't want my application code to change. That implies a Motor interface and different implementation bundles. Obviously that means that various motor types would require individual implementations with the correct controls implemented and requisite configuration files for modifying values (I might want to change the linearity of my motor response based on how a percentage value is mapped to the PAM or PPM values). But those would be configuration changes and not code changes.
Before any geek or manufacturer could contemplate contributing such implementations to a public Maven repository, they'd have to be able to count on standardized service interfaces. There might be a pie fight over what methods belong on such interfaces or what the events fired from such services might look like but that seems an acceptable discussion for such a key concern.
Once such libraries become common though, it would be a self-perpetuating system. If I'm a manufacturer of RFID readers and developers start inquiring about my OSGi/jar bundle implementation of the RFIDReader interface, I'd be inclined to make sure an implementation was up in the public Maven repos. Having exemplar implementations and test suites would make that a simple(r) exercise. Being able to rely on standard APIs and service factories for GPIO, I2C, and SPI interfaces means that as the RFID reader manufacturer I don't have to be concerned about what board is implementing the service interface for various board level devices. On the other hand, I could readily test my implementation on a variety of boards - without having to change my implementation code.
As more companies become interested in IoT and put more developers on coding tasks, fewer of them will have a Fluke DMM or o'scope sitting at their elbow ready to measure values coming off various pins. They will be Java and OSGi developers who simply want to write application/business level code. OSGi is perfect for this level of abstraction and a reason I find the Kura project rather compelling.
But those regular Java and OSGi application developers aren't going to have the knowledge or time or desire to look into pulling pins high or low or modulating signals in the correct fashion.
At the very least, static factory methods on things like the DeviceManager should be private to the bundles and exported as services so that device level details are hidden. Moving from board to board should be as easy as changing the board level bundle implementation I'm using to access the service factories and services. Sure, I'll have to modify the configuration file(s) to export or configure the devices, that my application requires. But it's a configuration change and not a code change.
Again, I'm not sure if the sensor/actuator APIs and services are a concern or of interest to the Kura project. I'm trying to understand that now and contribute to a project where they are. In any case, they will be needed and maybe a different project is required for them. At the very least, though, the export of OSGi services and service factories for board level devices will be necessary.
One last example, perhaps as a board maker I don't want to use the Pi4j libraries but want to implement lower level libraries to provide higher resolution and faster operation. If it is encapsulated in my implementation bundle and exported as those same services and service factories, then developers higher up the stack can benefit without being aware of those details.
Whew, this got to be a bit more long winded than I'd anticipated. This is something I'm keen to be involved in and really want to see these levels of abstractions. While I'm passingly familiar with the electronics aspects I'm more experienced with OSGi and its idioms.
Brad
[Updated on: Wed, 04 January 2017 13:48] by Moderator |
|
|
Powered by
FUDForum. Page generated in 0.03754 seconds
Home