[ https://issues.apache.org/jira/browse/KARAF-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169185#comment-17169185 ]
Robert Varga commented on KARAF-6625: ------------------------------------- Thinking about this a bit more, this actually might be a maven-bundle-plugin or bnd bug. In this particular case the factory component referenced is in the same bundle. As per 112.5.5 of Compendium (R6 and R7): {noformat} SCR must register a Component Factory service as soon as the component factory becomes satisfied. {noformat} and {noformat} The Component Factory service must be registered under the name org.osgi.service.component.ComponentFactory with the following service properties: • component.name - The name of the component. • component.factory - The value of the factory attribute. {noformat} Hence while the ComponentFactory requirement is not *directly* provided by the bundle, it is provided *indirectly* via the bundle's interaction with SCR: once the factory component (defined by the bundle) becomes satisflied, SCR will register the ComponentFactory on the bundle's behalf. I therefore think maven-bundle-plugin should have generated the matching Provide-Capability manifest entry. An alternative interpretation would be that SCR bundle potentially provides ComponentFactory and therefore it is a Felix bug, as it does not specify it. I lean towards the former, as that allows more precise control over Requires/Provides: we can bind on the actual service properties (i.e. provide constrained to component.factory=XXX, just as the bundle's requirement is constrained to @Reference.target = "(component.factory=XYZ)". [~jbonofre] what is your opinion on this analysis? > feature:install fails for bundles with SCR Factory Components > ------------------------------------------------------------- > > Key: KARAF-6625 > URL: https://issues.apache.org/jira/browse/KARAF-6625 > Project: Karaf > Issue Type: Bug > Components: karaf > Affects Versions: 4.2.8 > Reporter: Robert Varga > Assignee: Jean-Baptiste Onofré > Priority: Major > > This issue has been reported in the thread here: > [https://mail-archives.apache.org/mod_mbox/karaf-user/201809.mbox/%3c224b2d59-43ca-f01c-ea77-b2f7ba2a7...@nanthrax.net%3e] > If a bundle is created using stock maven-bundle-plugin (4.2.1), without > specifying: > {noformat} > <_dsannotations-options>norequirements</_dsannotations-options>{noformat} > and is using Factory Components > ([https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#d0e39673] > , but it works the same way for R6), it results in MANIFEST.MF containing: > {noformat} > Require-Capability: > osgi.service;filter:="(objectClass=org.osgi.service.component.ComponentFactory)";effective:=active > {noformat} > This is not handled properly at feature:install time and resulting in: > {noformat} > karaf@root()> feature:install odl-mdsal-binding-runtime > org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: > missing requirement [root] osgi.identity; > osgi.identity=odl-mdsal-binding-runtime; type=karaf.feature; > version="[6.0.0.SNAPSHOT,6.0.0.SNAPSHOT]"; > filter:="(&(osgi.identity=odl-mdsal-binding-runtime)(type=karaf.feature)(version>=6.0.0.SNAPSHOT)(version<=6.0.0.SNAPSHOT))" > [caused by: Unable to resolve odl-mdsal-binding-runtime/6.0.0.SNAPSHOT: > missing requirement [odl-mdsal-binding-runtime/6.0.0.SNAPSHOT] osgi.identity; > osgi.identity=org.opendaylight.mdsal.binding-runtime-osgi; type=osgi.bundle; > version="[6.0.0.SNAPSHOT,6.0.0.SNAPSHOT]"; resolution:=mandatory [caused by: > Unable to resolve org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT: > missing requirement > [org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT] osgi.service; > filter:="(objectClass=org.osgi.service.component.ComponentFactory)"; > effective:=active]] > at > org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343) > at > org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392) > at > org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378) > at > org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332) > at > org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257) > at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:393) > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062) > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to > resolve odl-mdsal-binding-runtime/6.0.0.SNAPSHOT: missing requirement > [odl-mdsal-binding-runtime/6.0.0.SNAPSHOT] osgi.identity; > osgi.identity=org.opendaylight.mdsal.binding-runtime-osgi; type=osgi.bundle; > version="[6.0.0.SNAPSHOT,6.0.0.SNAPSHOT]"; resolution:=mandatory [caused by: > Unable to resolve org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT: > missing requirement > [org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT] osgi.service; > filter:="(objectClass=org.osgi.service.component.ComponentFactory)"; > effective:=active] > at > org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343) > ... 12 more > Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to > resolve org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT: missing > requirement [org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT] > osgi.service; > filter:="(objectClass=org.osgi.service.component.ComponentFactory)"; > effective:=active > at > org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343) > ... 13 more > {noformat} > Adding above _dsannotations-options supresses the manifest entry and > everything works as expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)