On Thu, Sep 29, 2016 at 10:36 AM, Guillaume Nodet <[email protected]> wrote: > > > 2016-09-29 16:22 GMT+02:00 Benson Margulies <[email protected]>: >> >> 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? > > >> <startupFeatures> >> <feature>rosapi-worker-flinx-sdk</feature> >> </startupFeatures> > > >> >> > >> > 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? > > > Definitely not. I'm not even sure that would work during the boot because > the bundles part of the prerequisite feature may not even start if the start > level is too high. > So if you're problem is start order of the bundles, use the start level on > bundles. > > Fwiw, if feature S requires javax.servlet, it would be better to add that > bundle as a <bundle dependency="true">xxx</bundle> or have a <feature > dependency="true">http</feature>. There's very few valid reason why a > feature should not be transitively closed.
I will close this thread for now (as far as I am concerned) by merely observing that when you use the maven plugin to build your features, there are many opportunities to fail to do this. Thanks again for all the help. > >> >> >> 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/ >> > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
