Harshan,
The purpose of descriptor was to remove boiler plate code. If there is
anything specific, use the handwritten plugin approach.
If it's not already there, let's make both descriptor and handwritten
plugin to co-exist on a single runtime.
On Thu, Dec 1, 2016 at 1:25 PM, Harshan Liyanage
Hi Ayyoob,
There are some instances where we need to cater plugin-specific
functionalities which can't be achieved through a boiler-plate
implementation. This behavior can be seen in mostly mobile-device plugins.
For most of the times we don't need specific internal implementation. For
example
Hi Dilan,
> Does this mean we can basically have a ready-to-use device plug-in
> implementation, just by configuring a descriptor file ?
>
Yes thats the idea, In here the plugin means the osgiService which contains
the definition of the device type. we found from the existing device type
that it
Pretty useful. This also makes the device plugins deployable without
restarting the server.
I believe we can extend the same to write hot deployable device plugins
using Java (no OSGi).
On Tue, Oct 25, 2016 at 9:02 PM, Ayyoob Hamza wrote:
> Hi All,
>
> Current structure for
Hi All,
Current structure for device type plugin for WSO2 IoT looks like following:
devicetype-plugin
| - device manager extension (An OSGi service )
| - api (jax-rs)
| - UI
| - analytics (descriptors - deployer)
However, what goes inside device manager extension component is pretty much
a