Isn't the purpose of osgi.wiring.host namespace to expose the information in the bundle headers for the purpose of fragments (according to core spec chapter 8.5)?
In the repo.xml example, the be.aca.service resource does have a capability osgi.wiring.package that exposes be.aca.service.api. Imho, that is sufficient for the repository to know that be.aca.service is the bundle that exposes this package. The be.aca.service-user bundle has a requirement for package be.aca.service.api, so it should be able to resolve to the be.aca.service bundle. This seems to be a bit of a detour to get to the actual thing we're trying to achieve, and that is to also put subsystems in the repo.xml (manually for now, because there is no tooling yet), and being able to deploy a top-level subsystem which then 'pulls in' its dependencies from the repo automatically. But since we can't even get it to work with bundles, we were wondering if it could ever work with subsystems. Besides this, we're also not sure how to put subsystems in the repo.xml, how the capabilities and requirements are to be expressed. (btw, I'm working on the same issue as Tim ;-) ) Thanks again for any help! Jeroen On Thu, Mar 26, 2015, at 06:00, Kamesh Sampath wrote: > From simple test I made with my work sample, I tried adding the > following to *repo.xml* > > To "API Bundle (be.aca.service.api)" > > > " <capabilitynamespace="osgi.wiring.host"> > <attributename="osgi.wiring.host"value="be.aca.service"/> > <attributename="bundle-version"type="Version"value="0.0.1-SNAPSHOT"/> > </capability> > " > > To "Provider or Requirer bundle (be.aca.service-user)" > " > <capabilitynamespace="osgi.service"> > <attributename="objectClass"type="List<String>"value="be.aca.service.api"/> > > </capability> > " > In my perception the API bundle exporting the packages but the wiring > bundles does not know which host exports the API so we need to define > the `wiring.host` name in the API bundle and list the services that > provider or requirer might use. > HTH > > > > > — *Kamesh Sampath* Sr.Architect, Liferay India Twitter[1] |LinkedIn[2] > >> On 25-Mar-2015, at 6:35 pm, Tim Vissers >> <[email protected]> wrote: >> >> Ok, that I understand. >> >> However in my question we're not yet using subsystems, the question >> (A) is just about bundle resolving using the repo.xml, not subsystems >> >> 2015-03-25 13:52 GMT+01:00 Kamesh Sampath >> <[email protected]>: >>> sorry my bad i did not notice it. >>> >>> but right now we can’t generate subsystem indexing in the repo using >>> the available tools, even my personal experience as you had i was >>> able to do it only via maven:bundle indexing which tries to resolve >>> the subsystem content form the maven repo, the repoindex does not >>> index the esa as it does not know how/what to index, currently even >>> in OSGi spec we dont have the right defs for it. >>> >>> @David, please feel to add if i had missed any point. >>> >>> >>> — *Kamesh Sampath* Sr.Architect, Liferay India Twitter[3] >>> |LinkedIn[4] >>> >>> >>>> >>>> On 25-Mar-2015, at 6:12 pm, Tim Vissers <[email protected]> >>>> wrote: >>>> >>>> >>>> It's not a bundle, it's a api package that is exported in >>>> be.aca.service and imported in be.aca.service-user. en t Tim >>>> >>>> >>>> >>>> 2015-03-25 13:38 GMT+01:00 Kamesh Sampath >>>> <[email protected]>: >>>> >>>>> am not seeing be.aca.service.api in the obr:list, where is that >>>>> bundle ? >>>>> >>>>> >>>>> — *Kamesh Sampath* Sr.Architect, Liferay India Twitter[5] >>>>> |LinkedIn[6] >>>>> >>>>> >>>>>> On 25-Mar-2015, at 6:02 pm, Tim Vissers <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> be.aca.service.api >>>>> >>>> >>>> >>> >> > Links: 1. https://twitter.com/@kamesh_Sampath 2. http://in.linkedin.com/pub/kamesh-sampath/4b/934/338/ 3. https://twitter.com/@kamesh_Sampath 4. http://in.linkedin.com/pub/kamesh-sampath/4b/934/338/ 5. https://twitter.com/@kamesh_Sampath 6. http://in.linkedin.com/pub/kamesh-sampath/4b/934/338/
