Re: [iot-wg] Why use concierge?

[Jens Reimann <jens.reimann@xxxxxxxxxxxxxxx>]

Hello Pascal,

Thanks for your answers.

We already start Eclipse without the native launcher in most cases.
Wrapped by a Python script to find the correct jar. However you
sometimes get some native bundles in there. I am not sure if this is
Equinox or the Eclipse Runtime though.

For P2 I find it rather hard to find god starting points for alternative
solutions. I think it does what it is intended to do, and it does it
good. But you pretty soon get lost when it comes to alternative
launching and provisioning ways (beside the Eclipse IDE). I don't blame
anyone, I know how hard it is to write documentation ;-)

Also is the whole Eclipse way a bit more powerful than plain OSGi. As
far as I know OSGi proposes OBR for provisioning. However I did find no
support for that in Equinox or P2. I think it was Felix that allowed
installing bundles directly from Maven repositories, which would also be
an alternative way.

I also have to admit that I am not sure what the best way actually is
for small devices. On the one hand you want to be flexible and only
install the bundles that you need. It may be nice to do this manually
("clicking" together your system with dependencies). On the other hand
if you have 100s of devices and every device is special you don't want
to maintain this manually.

But I guess all this should be subject to a different post :)

And yes "more independence from Equinox in your application" correct.

Jens

On 04/27/2014 04:17 AM, Pascal Rapicault wrote:
> Hi Jens
>
> Answer embedded.
>
> On 24/04/2014 4:52 AM, Jens Reimann wrote:
>> Hello Pascal,
>>
>> I don't want to sound negative, but from the viewpoint of Eclipse SCADA
>> we are pretty happy with Equinox ;-)
>>
>> But we also learned, the hard way, that Equinox seems to make a lot of
>> "special things". That might be easier at first, but creates problems
>> when other OSGi containers become a topic. At the moment we are not able
>> to deploy to other OSGi containers since we need P2 and EMF
>>
>> For EMF we really do need EMF. But for P2, we only require a some sort
>> of build -> provision toolchain. Which is Maven Tycho (p2) -> P2
>> Director at the moment.
>>
>> Our long term goal is to also have other, more pure, OSGi containers.
>> Also not needing any native code in order to launch the framework. And
>> for this we would like to use technology coming from the Eclipse
>> eco-system.
>     The framework can be started w/o the native launcher. For example
> you can start the Eclipse IDE by running java -jar
> plugins/org.eclipse.equinox.launcher_....jar and you can also directly
> start equinox itself in a similar way (java -jar
> org.eclipse.osgi_...jar). You can also see code embedding Equinox in
> Tycho.
>
>> For this we would need Declarative Services (DS) and some sort of
>> provision mechanism. P2 is a bit bulky, but works fine for our case. We
>> do use the P2 director to assemble our applications (depending from the
>> System Configuration the user created). This done on either the
>> configuration machine or the target machine. There is no "online
>> update". So if we have a system configuration with 10 servers and each
>> server has 2 different applications, all applications are provisioned
>> using the P2 director from the initial set of P2 repositories.
>     It is true that p2 is a bit bulky and is currently known to only
> run on Equinox. However p2 has been designed to run and provision
> other frameworks. In fact back when we started we were able to
> provision Felix. At this point I don't know exactly what it would take
> to make that work again, but I think this is in the real of
> possibilities.
>     The other thing you may be interested in is in knowing that there
> has been designs and prototypes done in p2 to make it work "after the
> fact". Meaning that you would not need to have the p2 folder and all
> that in your application. Instead p2 would be able to reason about the
> currently installed bundle and take it from there to perform the
> installation (still bringing transactionality and dependency resolution).
>
>>
>> However we also see a shift at the moment from this deployment scheme,
>> to a more distributed scheme. In the the past we had two big servers,
>> and that's it. At the moment systems go up to 20 different nodes which
>> are (compared to then) less powerful. And we now start to have ARM based
>> devices which will have even less performance and greater numbers.
>>
>> So in the end the three most important reasons for us to move to a
>> different OSGi container are:
>> -) Better provisioning
>     Maybe a topic of the p2-dev mailing list, but I would be
> interested in knowing what are the criteria for a better provisioning.
>
>> -) Less (or better no) native dependencies (launcher)
>     See note above.
>> -) Better compatibility with OSGi
>     I m assume you mean more independence from Equinox in your
> application, or do you have something else in mind
>
> Thanks
>
> Pascal
>
>>
>> Jens
>>
>> On 04/23/2014 06:19 PM, Pascal Rapicault wrote:
>>> Hi,
>>>
>>> Since Concierge has been released, I noticed a lot of interest from
>>> the variou IoT projects to move to concierge from Equinox and I would
>>> like to understand the motivation of such a move? I can obviously get
>>> the size argument, but is there more to it?
>>>
>>> Thanks
>>>
>>> Pascal
>>> _______________________________________________
>>> iot-wg mailing list
>>> iot-wg@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/iot-wg
>>
>> _______________________________________________
>> iot-wg mailing list
>> iot-wg@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/iot-wg
>
> _______________________________________________
> iot-wg mailing list
> iot-wg@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/iot-wg