Are you saying that OBR as it stands today cannot resolve the generic requirement/capabilities from OSGi R4.3?
Thanks Alasdair On 20 September 2011 18:18, Guillaume Nodet <[email protected]> wrote: > Yeah, I agree that would be a good idea. We just need to have an > implementation to support those in obr first. > > On Tue, Sep 20, 2011 at 19:07, Alasdair Nottingham <[email protected]> wrote: > > > +1 > > > > I'd do a +∞ but I don't think that is valid, and I don't know if you can > > see > > the infinity symbol. > > > > Alasdair > > > > On 20 September 2011 15:01, Richard S. Hall <[email protected]> > wrote: > > > > > On 9/20/11 9:47 AM, Guillaume Nodet wrote: > > > > > >> The osgi core spec specifies how the osgi framework behaves. This > > header > > >> is not used anymore by the osgi framework, and only mentioned as being > > for > > >> informational purposes, which is how we use it here (from the osgi > core > > >> point of view). > > >> > > >> That said, I'll add this header back as its presence doesn't really > > cause > > >> any trouble, while its removal actually broke my applications (because > > >> it's > > >> used by the maven bundle plugin and felix obr implementation). > > >> > > >> I don't have any problem changing the whole solution, but I'd much > > rather > > >> do > > >> that when the new obr spec will be published and the felix > > implementation > > >> done, so that we can have a nice way to express those constraints. I > > >> don't > > >> really want to change the whole thing twice in a year. This would > also > > >> be > > >> a good time to discuss a way to indicate how extenders information can > > be > > >> put into those obr constraints and leveraged nicely. > > >> > > > > > > You actually don't need to wait for the OBR spec to be able to express > > > these dependencies. In fact, the OBR spec doesn't say how to express > > them. > > > However, the R4.3 core spec released earlier this year introduced > > > Provide-Capability/Require-**Capability headers that can be used right > > > now. So, you might as well start using them. > > > > > > -> richard > > > > > > > > > > > >> On Tue, Sep 20, 2011 at 15:01, Alasdair Nottingham<[email protected]> > > >> wrote: > > >> > > >> No it doesn't, however that is irrelevant in my mind. Standards exist > > for > > >>> a > > >>> reason. This header is owned and specified by the OSGi alliance. If > you > > >>> want > > >>> to use a more expressive syntax you can invent your own header. If > > people > > >>> ignore standards because "it doesn't work for them" then what value > do > > >>> standards provide. > > >>> > > >>> Alasdair > > >>> > > >>> On 20 September 2011 12:23, Guillaume Nodet<[email protected]> > wrote: > > >>> > > >>> Well, does it actually cause any problem to you ? I've asked more > > than > > >>>> once > > >>>> but had no answer. > > >>>> Because removing those headers actually cause problems to me. > > >>>> > > >>>> Fwiw, the discussions we had in the felix community lead that those > > >>>> > > >>> headers > > >>> > > >>>> were acceptable. > > >>>> Maybe we can revisit and find a better way with the new OBR spec > > >>>> provided > > >>>> that those constraints can be captured. > > >>>> > > >>>> On Tue, Sep 20, 2011 at 11:14, Alasdair Nottingham<[email protected]> > > >>>> > > >>> wrote: > > >>> > > >>>> > > >>>> Hi, > > >>>>> > > >>>>> As I have said many times in the past it is not valid to put > > attributes > > >>>>> into > > >>>>> an Import-Service header. The OSGi Alliance specification that > > defines > > >>>>> > > >>>> the > > >>>> > > >>>>> syntax says it is a comma separated list of service interface/class > > >>>>> > > >>>> names. > > >>>> > > >>>>> I > > >>>>> support any effort that reduces the use of invalid OSGi header > > syntax. > > >>>>> > > >>>>> Alasdair > > >>>>> > > >>>>> On 20 September 2011 08:12, Guillaume Nodet<[email protected]> > > wrote: > > >>>>> > > >>>>> Unless I hear something, I plan to revert this change. > > >>>>>> > > >>>>>> On Thu, Sep 8, 2011 at 15:42, Guillaume Nodet<[email protected]> > > >>>>>> > > >>>>> wrote: > > >>>> > > >>>>> > > >>>>>> What is the reason for removing those informations ? > > >>>>>>> Those are used when computing the obr constraints ... and > actually > > >>>>>>> used when resolving using OBR. > > >>>>>>> > > >>>>>>> On Thu, Jul 28, 2011 at 10:48,<[email protected]> wrote: > > >>>>>>> > > >>>>>>>> Author: cziegeler > > >>>>>>>> Date: Thu Jul 28 08:48:27 2011 > > >>>>>>>> New Revision: 1151765 > > >>>>>>>> > > >>>>>>>> URL: http://svn.apache.org/viewvc?**rev=1151765&view=rev< > > http://svn.apache.org/viewvc?rev=1151765&view=rev> > > >>>>>>>> Log: > > >>>>>>>> FELIX-2156 - Remove Import-Service header in MANIFEST > > >>>>>>>> > > >>>>>>>> Modified: > > >>>>>>>> felix/trunk/eventadmin/impl/**changelog.txt > > >>>>>>>> felix/trunk/eventadmin/impl/**pom.xml > > >>>>>>>> > > >>>>>>>> Modified: felix/trunk/eventadmin/impl/**changelog.txt > > >>>>>>>> URL: > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> http://svn.apache.org/viewvc/**felix/trunk/eventadmin/impl/** > > >>> changelog.txt?rev=1151765&r1=**1151764&r2=1151765&view=diff< > > > http://svn.apache.org/viewvc/felix/trunk/eventadmin/impl/changelog.txt?rev=1151765&r1=1151764&r2=1151765&view=diff > > > > > >>> > > >>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> ==============================**==============================** > > >>> ================== > > >>> > > >>>> --- felix/trunk/eventadmin/impl/**changelog.txt (original) > > >>>>>>>> +++ felix/trunk/eventadmin/impl/**changelog.txt Thu Jul 28 > > 08:48:27 > > >>>>>>>> > > >>>>>>> 2011 > > >>>>> > > >>>>>> @@ -7,6 +7,9 @@ Changes from 1.2.12 to 1.2.14 > > >>>>>>>> * [FELIX-3053] - Potential deadlock if event handler throws > > >>>>>>>> > > >>>>>>> Throwable > > >>>>>> > > >>>>>>> and is bypassing timeout handling > > >>>>>>> > > >>>>>>>> * [FELIX-3055] - Event Admin deadlocks when sendEvent is > > >>>>>>>> > > >>>>>>> called > > >>> > > >>>> from > > >>>>>> > > >>>>>>> within a handleEvent method > > >>>>>>> > > >>>>>>>> > > >>>>>>>> +** Improvement > > >>>>>>>> + * [FELIX-2156] - Remove Import-Service header in MANIFEST > > >>>>>>>> + > > >>>>>>>> > > >>>>>>>> Changes from 1.2.10 to 1.2.12 > > >>>>>>>> ----------------------------- > > >>>>>>>> > > >>>>>>>> Modified: felix/trunk/eventadmin/impl/**pom.xml > > >>>>>>>> URL: > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> http://svn.apache.org/viewvc/**felix/trunk/eventadmin/impl/** > > >>> pom.xml?rev=1151765&r1=**1151764&r2=1151765&view=diff< > > > http://svn.apache.org/viewvc/felix/trunk/eventadmin/impl/pom.xml?rev=1151765&r1=1151764&r2=1151765&view=diff > > > > > >>> > > >>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> ==============================**==============================** > > >>> ================== > > >>> > > >>>> --- felix/trunk/eventadmin/impl/**pom.xml (original) > > >>>>>>>> +++ felix/trunk/eventadmin/impl/**pom.xml Thu Jul 28 08:48:27 > 2011 > > >>>>>>>> @@ -98,14 +98,6 @@ > > >>>>>>>> </Import-Package> > > >>>>>>>> > > >>>>>>>> <Export-Package>org.osgi.**service.event</Export-Package> > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> <Private-Package>org.apache.**felix.eventadmin.impl.*</** > > >>> Private-Package> > > >>> > > >>>> -<Import-Service> > > >>>>>>>> - > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> org.osgi.service.event.**EventHandler;availability:=** > > >>> optional;multiple:=true, > > >>> > > >>>> - > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>> org.osgi.service.log.**LogService;availability:=** > > >>> optional;multiple:=false, > > >>> > > >>>> - > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> org.osgi.service.log.**LogReaderService;availability:** > > >>> =optional;multiple:=false > > >>> > > >>>> -</Import-Service> > > >>>>>>>> -<Export-Service> > > >>>>>>>> - org.osgi.service.event.**EventAdmin > > >>>>>>>> -</Export-Service> > > >>>>>>>> <!-- Include concurrent lib but not sub > > >>>>>>>> > > >>>>>>> packages > > >>>>>> > > >>>>>>> --> > > >>>>>>> > > >>>>>>>> <Embed-Dependency> > > >>>>>>>> > > >>>>>>>> concurrent;inline="EDU/oswego/**cs/dl/util/concurrent/[A-Z]*" > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -- > > >>>>>>> ------------------------ > > >>>>>>> Guillaume Nodet > > >>>>>>> ------------------------ > > >>>>>>> Blog: http://gnodet.blogspot.com/ > > >>>>>>> ------------------------ > > >>>>>>> Open Source SOA > > >>>>>>> http://fusesource.com > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> ------------------------ > > >>>>>> Guillaume Nodet > > >>>>>> ------------------------ > > >>>>>> Blog: http://gnodet.blogspot.com/ > > >>>>>> ------------------------ > > >>>>>> Open Source SOA > > >>>>>> http://fusesource.com > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> Alasdair Nottingham > > >>>>> [email protected] > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> -- > > >>>> ------------------------ > > >>>> Guillaume Nodet > > >>>> ------------------------ > > >>>> Blog: http://gnodet.blogspot.com/ > > >>>> ------------------------ > > >>>> Open Source SOA > > >>>> http://fusesource.com > > >>>> > > >>>> > > >>> > > >>> > > >>> -- > > >>> Alasdair Nottingham > > >>> [email protected] > > >>> > > >>> > > >> > > >> > > >> > > > > > > -- > > Alasdair Nottingham > > [email protected] > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
