> Since both bundles B and C offer to export the api.a package, the framework
> could resolve both bundles to each export the package. Thus you can end up
> with 2 exports of the api.a package in the framework. So bundle D will import
> api.a from either bundle B or bundle C and thus will not be able to see the
> service from the other bundle since it is not type compatible.
Maybe I lack some basic knowledge about Java class loading, but I thought that
as the packages were at the same version there was nothing that can really
distinguish them, the framework will choose to use one of the packages from a
specific location (eg; Bundle B) and so the services could not be impacted by a
type compatibility issue. This is what I understand from the blog post sent by
Ray too: "Because the OSGi framework controls the classloading on the package
level, when multiple bundles export the API package(s), the OSGi framework can
decide which exporting bundle ultimately provides the API package(s) to each
bundle importing the API, that is, to each API consumer.". But as I can
factually see and from your explanation things can happen differently?!
> You may want to also look at
> https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html
Thanks for the link. In the section Going Forward, it is wrote that we should
consider not embedding API packages that are defined by OSGi specifications,
does this advice also holds for our own service definitions?
When building a system with multiple related features does it makes sens to
provide a compile time Bundle with all the API packages, and, one runtime API
Bundle for each API packages? Is it what the blog post is telling us? What is
the relation between osgi.cmpn and the set of osgi runtime API bundles?
I like to have one API bundle per workspace, it makes dependency management
easier and I have one unique project to be careful with. Would it be relevant
that bnd/bndtools provides a support to release multiple runtime API Bundles
from one API project simply by configuring something in the bnd.bnd file. I am
not sure to be clear, but this is to control the number of projects needed.
Another solution would be to make the API Bundle resolvable, but I had some
issue with that in the past...
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday 11 March 2020 14:19, Raymond Auge <raymond.a...@liferay.com> wrote:
> Hi Clément,
>
> You may want to also look at
> https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html
>
> :)
>
> - Ray
>
> On Wed, Mar 11, 2020 at 9:16 AM BJ Hargrave via osgi-dev
> <osgi-dev@mail.osgi.org> wrote:
>
>> Since both bundles B and C offer to export the api.a package, the framework
>> could resolve both bundles to each export the package. Thus you can end up
>> with 2 exports of the api.a package in the framework. So bundle D will
>> import api.a from either bundle B or bundle C and thus will not be able to
>> see the service from the other bundle since it is not type compatible.
>>
>> In this scenario, it is better to have only a single exporter of api.a.
>> Bundle A would be the best choice here as it is the original source of the
>> package. But you would need to allow it to be resolvable so it can be used
>> at runtime.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com
>>
>>> ----- Original message -----
>>> From: "Clément Delgrange via osgi-dev" <osgi-dev@mail.osgi.org>
>>> Sent by: osgi-dev-boun...@mail.osgi.org
>>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
>>> Cc:
>>> Subject: [EXTERNAL] [osgi-dev] Service binding issue and package wiring
>>> Date: Wed, Mar 11, 2020 08:13
>>>
>>> Hi all,
>>>
>>> I have some sparse service binding issues at runtime that I think are
>>> related at how my bundles export packages.
>>>
>>> Here is what I have:
>>> - Bundle A exports API package api.a and is not resolvable (not present at
>>> runtime).
>>> - Bundle B provides api.a.Service1 service and export/import api.a package.
>>> - Bundle C provides api.a.Service2 service and export/import api.a package.
>>> - Bundle D consumes Service1 or Service2 and import api.a package.
>>>
>>> In this case is there any reason related to the way packages are wired that
>>> could lead bundle D to not get Service1 or Service2? Subsidiary question,
>>> is it fine to have an API package partly provided by two different bundles
>>> when provider bundles embed their API?
>>>
>>> In a more general practice, for a specific functionality, I have often one
>>> core service contract, some DTOs and some DAO services. Which one of this
>>> combination is better (considering that I have always an unresolvable API
>>> bundle and my providers export the API package they provide):
>>>
>>> - Core service, DAOs and DTOs in one API package then two providers, one
>>> for the core service implementation and DTOs and the other for the DAOs
>>> implementation.
>>> - Core service, DAOs and DTOs split in different API packages then three
>>> providers, one for each.
>>>
>>> Regards,
>>> Clement
>>> _______________________________________________
>>> 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
>
> --
> [Raymond Augé](http://www.liferay.com/web/raymond.auge/profile) (@rotty3000)
> Senior Software Architect [Liferay, Inc.](http://www.liferay.com) (@Liferay)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
