And btw, given the code to remove service requirements is already present, we could go a bit more fine grained and add a flag on the feature xml element to disable/enforce service requirements :
<feature name="foo" serviceRequirements="disable|default|enforce" ...> That should be fairly easy to do in a 1.5 schema for Karaf 4.1 imho. 2016-08-25 18:44 GMT+02:00 Guillaume Nodet <[email protected]>: > 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/ > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
