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
