Remote OSGi is a good example, but then then API can be viewed the provider.
Kind regards,
Peter Kriens
> On 9 Feb 2018, at 01:12, Scott Lewis via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
> I think cases where the service consumer doesn't need or want the provider
> code (e.g. small or embedded environments) is one such example. In such
> cases a separate API can keep things smaller and less complicated on the
> consumer.
>
> Scott
>
> On 2/8/2018 12:54 PM, Peter Kriens via osgi-dev wrote:
>> I think there are only a few good cases where you really need an API bundle.
>> Virtually cases I’ve seen in the wild were incorrect because they fudged the
>> versions to make the API more backward compatible than it really was so more
>> providers could leverage it. In very few cases can you have different
>> providers for the same API version.
>>
>> Exporting the API from the provider is usually the safest way imho and it
>> works very well without extra metadata with resolving.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>> On 8 Feb 2018, at 21:01, Chris Gray via osgi-dev <osgi-dev@mail.osgi.org>
>>> wrote:
>>>
>>> In my experience it is quite often handy to have a separate API bundle -
>>> yours is one use case, another is where the system may run on different
>>> platforms which require different implementations for some services (cloud
>>> vs development machine, embedded vs dev, self-contained demo vs real
>>> distributed system, ...). In fact in a way this is the "normal"
>>> configuration, provider-exports is a convenience.
>>>
>>> If the packages can be exported by both api bundle and provider then you
>>> have to watch out for "uses" constraint violations if versions diverge,
>>> Keep It Simple is the key here.
>>>
>>> Have fun
>>>
>>> Chris
>>>
>>>> I understand that with api compile only is not possible to run a remote
>>>> instance without the related provider bundle.
>>>>
>>>> With a provider with conditional package I have to resolve both api and
>>>> provider bundle because api packages are only copied inside provider but
>>>> not exported.
>>>> So I don’t think that is better than having api and provider separated.
>>>>
>>>> Now I’ve tried to modify my bundles in this way:
>>>> - api without compile only that export packages
>>>> - provider like before that export api packages
>>>>
>>>> With this configuration I can:
>>>> - run an osgi instance resolving only provider bundle like before
>>>> - run another instance without the provider resolving only api bundle
>>>>
>>>> Daniele
>>>>
>>>>
>>>> Da: David Daniel
>>>> Inviato: sabato 3 febbraio 2018 21:24
>>>> A: Dominik Przybysz; OSGi Developer Mail List
>>>> Cc: Daniele Pirola
>>>> Oggetto: Re: [osgi-dev] Api compile-only and remote services
>>>>
>>>> I think different projects handle it differently. The way I do it is if
>>>> only one provider loaded will implement the interface then I include the
>>>> interface in the provider with a conditional package and leave the api
>>>> compile only
>>>> http://enroute.osgi.org/tutorial_wrap/212-conditional-package.html If
>>>> multiple providers are going to implement the interface then I will change
>>>> the api bundle to a regular bundle to inclusion.
>>>> David
>>>>
>>>> On Sat, Feb 3, 2018 at 2:35 PM, Dominik Przybysz via osgi-dev
>>>> <osgi-dev@mail.osgi.org> wrote:
>>>> Hi,
>>>> if you know that you may run your bundles in distributed environment and
>>>> want to use Remote Services, your API bundles must be normal bundles.
>>>>
>>>> 2018-02-03 19:12 GMT+01:00 Daniele Pirola via osgi-dev
>>>> <osgi-dev@mail.osgi.org>:
>>>> Hi,
>>>> I have an Osgi workspace with many bundles with different "types": api,
>>>> provider and application. I follow enroute tutorials and my api bundles
>>>> are "compile only" and providers export api packages.
>>>> Now I would like to use osgi remote services but how can I use api
>>>> packages in different osgi instances without importing also the provider
>>>> that export these packages? I have to build another api project that only
>>>> export packages? Or api "compile only" is not the right thing for remote?
>>>>
>>>> Kind regards
>>>> Daniele
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pozdrawiam / Regards,
>>>> Dominik Przybysz
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>
>>>>
>>>>
>>> Mail priva di virus. www.avg.com
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
