Hi John, Ok, I see. So my assumption that the service requirement is coming from the manifest is wrong (and it is coming from the blueprint descriptor). However, this does not seem to work if a service required by a blueprint bundle is not provided by another blueprint bundle (but by other means). In my example it’s equinox’ event admin service. Is this really the intended behavior of the subsystem implementation? From my understanding the subsystem implementation should ignore service requirements and capabilities. I have tried to debug this, but I actually didn’t manage to really understand the interactions between the resolver and the ModelledResourceManager.
For the one example that I “fixed”: I changed one bundle providing a service from DS to blueprint. That did also create an Export-Service manifest header (but as I learned now the true reason why it worked afterwards was the blueprint descriptor). Best regards Stephan From: John W Ross [mailto:[email protected]] Sent: Dienstag, 27. August 2013 15:28 To: [email protected] Subject: Re: Import-Service and subsystems Aries Subsystems does not pay attention to either the Import-Service or Export-Service bundle manifest headers. They are not used to compute the service requirements or capabilities of bundles or subsystems. However, if the ModelledResourceManager service is present, service requirements and capabilities are computed using Blueprint. This is where your requirements are coming from. The fact that the maven bundle plugin generates Import-Service headers is incidental. I can't explain why adding the Export-Service header works other than simply stating that something outside of subsystems must be making it available as a service capability. For Aries Subsystems, a matching capability would typically be provided by Blueprint. John > > Import-Service and subsystems > > Hi, > > I have trouble with Import-Service manifest headers in bundles that > are contained in a subsystem. If there is an Export-Service manifest > header (in the subsystem or outside) everything is fine, however if > there is no such header, installation of the subsystem fails because > the dependency cannot be resolved. > > Is this intentional? The OSGi 5.0 core spec says about these headers > that they are deprecated and for informational purposes only, but > the maven bundle plugin generates them for exposed blueprint > services. The resolver and subsystem specifications don’t say > anything about this, so I am not really sure where to fix it (in the > resolver or in the Subsystem implementation (if I had to guess, it > might be somewhere with the SubsystemResource class). > > Best regards > Stephan
