Re: [smarthome-dev] Sample Karaf Distribution

[Markus Rathgeb <maggu2810@xxxxxxxxx>]

If I update my Eclipse IDE, I don't need to update all my installed
plugins myself (also the ones that are installed from the market
place).
The Updater is able to find updates of the plugins so they fit to the platform.

I don't think I have written that the market place needs to solve such
a situation.
But a logic in the client (so the SmartHome system) needs to find
compatible versions and needs to be able to resolve it.

If the market place could contain the same Binding with different
version constraints e.g.
* Binding A for ESH [1.1.0;1.2.0)
* Binding A for ESH [1.2.0;1.3.0)
my current understanding is that it could point to different URLs
(e.g. for Karaf the feature XML that is hosted somewhere)

If the system (e.g. the Karaf container) could update all its stuff
but nothing that is taken from the Market Place automatically -- e.g.
because there is no way to find the other "Binding A" (with the
knowledge "it's the same feature but other dependencies), I don't
think it is user friendly if the user needs -- after an update -- to
find a compativble version itself.

But as written above (or at least what I want to state):
I don't understand the whole market place topic.

2016-11-22 11:36 GMT+01:00 Kai Kreuzer <kai@xxxxxxxxxxx>:
>> As it is much simpler then report:
>
> Well, my suggestion would reduce this to:
>
> * install a plain Karaf
> * drop esh.kar into the deploy folder
>
>> So as long as I don't understand how a product can update the
>> stuff taken from the MP
>
> Why is this a mandatory requirement? See the MP as a repository of jars/kars, which people can browse and install.
> If they change their host container, they have to deal with that themselves. Just as you would have to do if you manually downloaded a kar file and installed it in your container.
>
>
>> On 21 Nov 2016, at 16:23, Markus Rathgeb <maggu2810@xxxxxxxxx> wrote:
>>
>> 2016-11-21 15:53 GMT+01:00 Kai Kreuzer <kai@xxxxxxxxxxx>:
>>> I would claim that the beauty of Karaf is that you don't NEED a custom distro (or at least, customizing it would show features of Karaf, but would have very little to do with ESH itself).
>>
>> You are right.
>> For me I created this simplest custom dist to reproduce bugs (and to
>> report reproducable bugs).
>> As it is much simpler then report:
>> * install a plain Karaf
>> * add feature repo karaf
>> * add feature repo karaf-tp
>> * install feature a, b, c
>>
>> But no reason to move it to eclipse repo space.
>>
>>> Possibly also building separate KARs for the different extensions, which would be a great step towards demonstrating how to package extensions for the upcoming IoT market place?
>>
>> I still don't understand the IoT market place as written in the bug
>> report. So as long as I don't understand how a product can update the
>> stuff taken from the MP if it updates its ESH stuff, I cannot think
>> about how it could be supported in Karaf.
>> _______________________________________________
>> smarthome-dev mailing list
>> smarthome-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/smarthome-dev
>
> _______________________________________________
> smarthome-dev mailing list
> smarthome-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/smarthome-dev