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 <gno...@apache.org>: > 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é <j...@nanthrax.net>: > >> 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 <gno...@apache.org> >>> 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é <j...@nanthrax.net>: >>>>> >>>>>> 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é <j...@nanthrax.net>: >>>>>>> >>>>>>> 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 >>>>>>>>> <krzys.sobkow...@gmail.com >>>>>>>>> >>>>>>>>>> >>>>>>>>>> : >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> +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é >>>>>>>> jbono...@apache.org >>>>>>>> http://blog.nanthrax.net >>>>>>>> Talend - http://www.talend.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Jean-Baptiste Onofré >>>>>> jbono...@apache.org >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >>>>> >>>> >>> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/
