Fragments are not allowed to declare the Service-Component header (or rather, if they do it will be ignored by SCR). It is however possible for the DS XML and/or classes to be located in fragments, so long as the Service-Component header is declared on the host bundle. So that may be one route.
Why not follow a composition approach rather than inheritance? You could have a single aggregator component that is injected with all the various services, and is then published as a service. Each of your smaller components can then inject the aggregate service component. Neil On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies <ben...@basistech.com> wrote: > Thanks to all of you who educated me yesterday about DS annotation > inheritance in bnd. I implemented it and it works very well. However, > I have an incremental challenge. > > What I have here is a gaggle of web services. Most of the logic is > common across them and lives in a base class, which now has @Reference > injection to pick up things it needs from the larger environment, and > activate/deactivate to manage lifecycle. > > However, I'd like to enable these services to come from disparate > teams. Given the injunction to avoid cross-bundle inheritance of the > DS annotations, I can't just export the package containing the base > class from one bundle and then tell the teams to import and inherit. > > It only took about five minutes to think of the idea of putting each > service in a fragment -- and then discard it, due to the fact that > fragments can't carry DS metadata (according to Stack Overflow). > > Is there another trail to follow here, or is there just an inescapable > dilemma between repeating DS annotations and decoupling the pieces? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
