2016-09-29 16:39 GMT+02:00 Benson Margulies <[email protected]>: > 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. >
Right, I don't really personally recommend to use the maven plugin to generate the feature files, I agree there's too many things that can go wrong. I usually write the features manually and validate them using the maven plugin. Once they are validated, the maven plugin can usually build custom distributions quite easily. > > > > >> > >> > >> 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/ > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
