You don't use any extender like DS or blueprint ? The capabilities can be easily auto-generated for those.
You can always disable service requirements globally by setting serviceRequirements = disable in the etc/org.apache.karaf.features.cfg config file. Guillaume 2016-08-25 16:17 GMT+02:00 Markus Rathgeb <[email protected]>: > So, is there a way to use 1.3.0 (IIRC prerequisite and dependency has > been added there) or newer without adding the capability instruction > to every feature using a bundle without that information in the > manifest? > I see there is a configuration for the runtime, but is there one for > the plugin to control the verification? > > I have to use a dozen of third party bundles that miss that > information and that change frequently, adding the capability to the > feature is a too time consuming effort. > > 2016-08-25 16:12 GMT+02:00 Guillaume Nodet <[email protected]>: > > Agreed, so the problem was caused by a custom feature ? > > I thought it was directly the pax-web feature. > > > > In that case, I agree, that's exactly the behavior we wanted I think. > > > > On a side note, if pax-web does not expose the service capability, it > > should also be fixed ;-) > > > > Guillaume > > > > 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > > > >> After digging a bit, I don't think it's actually a bug. > >> > >> Let me explain and see we all agree ;) > >> > >> Previously to the commit, the service enforcement was "enabled" only for > >> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service > >> enforcement also for xmlns 1.4.0 (which makes sense). > >> > >> In Markus' use case, he said he tried xmlns 1.2.0 and it failed. > However, > >> as he's using Karaf Maven plugin to generate the descriptor, by default, > >> even if the "source" features XML contains xmlns 1.2.0, the generated > one > >> is using xmlns 1.4.0. > >> > >> That's why it worked before and not after the commit. > >> > >> Due to that, I don't think we have to consider it as a bug: > >> 1. If we don't want service enforcement, than, we have to use a feature > >> with xmlns 1.2.0 > >> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver > >> features including services enforcement. > >> > >> WDYT ? > >> > >> Regards > >> JB > >> > >> > >> On 08/25/2016 03:41 PM, Jean-Baptiste Onofré wrote: > >> > >>> It looks like the commit in cause is the following: > >>> > >>> --------------------- > >>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit > >>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb > >>> Author: Guillaume Nodet <[email protected]> > >>> Date: Fri Jul 22 12:33:17 2016 +0200 > >>> > >>> [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema > >>> > >>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f > >>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M features > >>> ---------------------- > >>> > >>> I'm testing a revert. > >>> > >>> Regards > >>> JB > >>> > >>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofré wrote: > >>> > >>>> No, I don't think it's related as it's not a change in 4.0.6. > >>>> > >>>> I think it's a combination between the features resolver and the > >>>> karaf-maven-plugin. > >>>> > >>>> I'm pretty close in the bisect now ;) > >>>> > >>>> Regards > >>>> JB > >>>> > >>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote: > >>>> > >>>>> I found this one: > >>>>> > >>>>> # By default, the feature resolver checks the service > >>>>> requirements/capabilities of > >>>>> # bundles for new features (xml schema >= 1.3.0) in order to > >>>>> automatically installs > >>>>> # the required bundles. > >>>>> # The following flag can have those values: > >>>>> # - disable: service requirements are completely ignored > >>>>> # - default: service requirements are ignored for old features > >>>>> # - enforce: service requirements are always verified > >>>>> # > >>>>> #serviceRequirements=default > >>>>> > >>>>> Do you think this one could be related? > >>>>> > >>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a > >>>>> successful verification. > >>>>> > >>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"; > >>>>> name="${project.artifactId}-${project.version}"> > >>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"; > >>>>> name="${project.artifactId}-${project.version}"> > >>>>> > >>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > >>>>> > >>>>>> Hi Guillaume, > >>>>>> > >>>>>> I'm on git biset to identify the guilty ;) > >>>>>> > >>>>>> And yes, I will recut a release. > >>>>>> > >>>>>> Regards > >>>>>> JB > >>>>>> > >>>>>> > >>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote: > >>>>>> > >>>>>>> > >>>>>>> Yeah, if it breaks compatibility, we should recut a release ? > >>>>>>> Has anyone identified the culprit commit yet ? > >>>>>>> > >>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > >>>>>>> > >>>>>>> I think it's a change in the karaf-maven-plugin. > >>>>>>>> > >>>>>>>> And yes, I reproduce Markus' issue as well. > >>>>>>>> > >>>>>>>> Do we consider as release blocker ? > >>>>>>>> > >>>>>>>> If so, I will fix it today and submit a new vote. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> JB > >>>>>>>> > >>>>>>>> > >>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I was able to reproduce the issue Markus described with his test. > >>>>>>>>> One thing that crosses my mind, did we change something with the > >>>>>>>>> feature > >>>>>>>>> resolver? Cause I can't remember that the pax-web-api did > actually > >>>>>>>>> contain > >>>>>>>>> a provide-capability for the WebContainer Service. > >>>>>>>>> > >>>>>>>>> regards, Achim > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak > >>>>>>>>> <[email protected] > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> : > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> +1 (non-binding) > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!! > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> Krzysztof > >>>>>>>>>> > >>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote: > >>>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>>> > >>>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote. > >>>>>>>>>>> > >>>>>>>>>>> Release Notes: > >>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa? > >>>>>>>>>>> > >>>>>>>>>>> projectId=12311140&version=12335477 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Staging Repository: > >>>>>>>>>>> > >>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache > >>>>>>>>>>> karaf-1071/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Git Tag: > >>>>>>>>>>> karaf-4.0.6 > >>>>>>>>>>> > >>>>>>>>>>> Please vote to approve this release: > >>>>>>>>>>> > >>>>>>>>>>> [ ] +1 Approve the release > >>>>>>>>>>> [ ] -1 Don't approve the release (please provide specific > >>>>>>>>>>> comments) > >>>>>>>>>>> > >>>>>>>>>>> This vote will be open for at least 72 hours. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Regards > >>>>>>>>>>> JB > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak) > >>>>>>>>>> > >>>>>>>>>> JEE & OSS Architect, Integration Architect > >>>>>>>>>> Apache Software Foundation Member (http://apache.org/) > >>>>>>>>>> Apache ServiceMix Committer & PMC Member > >>>>>>>>>> (http://servicemix.apache.org/) > >>>>>>>>>> Senior Solution Architect @ Capgemini SSC > >>>>>>>>>> (http://www.capgeminisoftware. > >>>>>>>>>> pl/) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>> 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 > >>>>>> > >>>>> > >>>> > >>> > >> -- > >> 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/
