On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet <[email protected]> wrote: > Manually maintaining the feature set is not something you should do. > Please raise a JIRA and attach a test case if you can produce one (an > integration test for the plugin would be awesome) : that's not really > supported I think. > As a workaround, I would suggest you force the rosapi-worker-flinx-sdk to > be in the startup stage.
OK, can you tell me how to do that in the configuration of the karaf-maven-plugin? > > You really need this dependency as a prerequisite, right ? The only real > use case is for URL handlers used inside feature definitions. Anything > related to the wiring (packages, services, etc...) does not need to be a > prerequisite. As I tried to explain, this results from a mistake. We have a few bundles with activators that try to obtain services from other bundles, without properly accounting for indefinite startup order. I have code changes in train to use DS properly to fix this; these bundles were written some time ago when we barely understood OSGi. My foray into prerequisites is entirely a matter of trying to work around until the DS changes are in place. I am making a small experiment with start-level now since the prerequisite approach seems a bit, well, fraught. I will try to find time to make you a test case, it does appear as if it takes a somewhat complex collection of features and dependencies to elicit this problem, so it might take me a while. I might be able to describe the situation in a way that sheds some light for you in the interim: Feature Q declares feature R as a prerequisite. Feature R declares Feature S as an ordinary dependency (<feature>S</feature>). Feature S includes a bundle that imports javax.servlet, but does not include a bundle that exports javax.servlet. Instead, it normally gets that package from pax-jetty, which is not declared as a feature dependency at all. It's just included in the assembly. Maybe I should ask this question: if _all_ I need to control is startup order, and not wiring order, is 'prerequisite' even what I'm supposed to do? Thanks, benson > > > 2016-09-29 16:08 GMT+02:00 Benson Margulies <[email protected]>: >> >> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré <[email protected]> >> wrote: >> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is all >> > the >> > rest. >> > >> > I would recommend to group all dependency features in stage1 and the >> > rest in >> > stage2. >> >> How can I do that while still using the karaf-maven-plugin to write >> this file for me? Do I have to give up and manually maintain that >> property? >> >> Would the syntax be (a,b,c,d),e,g,f? >> >> thanks, >> benson >> >> >> >> > >> > Regards >> > JB >> > >> > >> > On 09/29/2016 03:54 PM, Benson Margulies wrote: >> >> >> >> Hi JB, >> >> >> >> I let the maven plugin write org.apache.karaf.features.cfg, so I don't >> >> know, to be honest, if I'm using multi-stage. >> >> >> >> _Without_ the failing prerequisites, I have the following content of >> >> org.apache.karaf.features.cfg. I'm using the property editor feature >> >> to turn off capability enforcement. >> >> >> >> >> >> rosapi-all-sdks is just a bag of <feature> declarations for other >> >> features. Things break when I try to make one of them a prerequisite >> >> of another. My problem is really to prevent the activation of a few >> >> bundles until another bundle is safely under control, and I am hoping >> >> for a workaround in the interim until we can really fix this with DS >> >> in a few weeks. >> >> >> >> >> >> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile >> >> #Thu Sep 29 09:49:19 EDT 2016 >> >> featuresBootAsynchronous=false >> >> serviceRequirements=disable >> >> featuresBoot = \ >> >> (wrap), \ >> >> log, \ >> >> rosapi-front-end-anvils-transport, \ >> >> bean-validation-support, \ >> >> rosapi-worker-common, \ >> >> ssh, \ >> >> rosapi-front-end-logstash-request-tracker, \ >> >> rosapi-front-end-service, \ >> >> aries-blueprint, \ >> >> feature, \ >> >> jaas, \ >> >> diagnostic, \ >> >> rosapi-worker-download-text-extraction-component, \ >> >> rosapi-front-end-null-request-tracker, \ >> >> bundle, \ >> >> rosapi-all-sdks, \ >> >> rosapi-front-end-local-usage-tracker, \ >> >> package, \ >> >> scr, \ >> >> rosapi-common, \ >> >> cxf-jaxrs, \ >> >> rosette-api, \ >> >> rosapi-front-end-embedded-transport, \ >> >> system, \ >> >> shell, \ >> >> shell-compat, \ >> >> config >> >> featuresRepositories = \ >> >> mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \ >> >> mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \ >> >> mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \ >> >> mvn:org.apache.karaf.features/framework/4.0.6/xml/features >> >> >> >> >> >> On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré <[email protected]> >> >> wrote: >> >>> >> >>> Hi Benson, >> >>> >> >>> do you use multi-stage in featuresBoot ? >> >>> >> >>> Regards >> >>> JB >> >>> >> >>> >> >>> On 09/29/2016 03:33 PM, Benson Margulies wrote: >> >>>> >> >>>> >> >>>> Folks, >> >>>> >> >>>> I build an assembly in which all the feature are boot features, >> >>>> because they are all going to be used. >> >>>> >> >>>> When I try to make one of them a prerequisite of another, I get a >> >>>> wiring error, because, apparently, the dependency tree at the package >> >>>> level is not being respected in wiring the bundles. >> >>>> >> >>>> All of this is a temporary stopgap until some components get correct >> >>>> DS @Reference dependencies, which some of them lack. >> >>>> >> >>>> Questions: Am I making an error using boot features? I realize that >> >>>> this report lacks specificity. I could try to build up a model on >> >>>> github. >> >>>> >> >>>> TIA, >> >>>> benson >> >>>> >> >>> >> >>> -- >> >>> Jean-Baptiste Onofré >> >>> [email protected] >> >>> http://blog.nanthrax.net >> >>> Talend - http://www.talend.com >> > >> > >> > -- >> > Jean-Baptiste Onofré >> > [email protected] >> > http://blog.nanthrax.net >> > Talend - http://www.talend.com > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
