I hope I can use this thread to piggyback a more general gripe. When I look at a framework implementation such as Felix 4.2.1, it's not immediately obvious what level of the OSGi specifications it supports. For example many people have erroneously assumed that Felix supports OSGi R5 because it exports version 1.7 of the org.osgi.framework package.
>From a tooling perspective this is a problem because there's no way to give the user a choice between different frameworks based on what spec level they support. I would like to see some kind of declaration – e.g. a Provide-Capability in the "osgi.framework" namespace? – using the manifest of the framework JAR. I know that the framework manifest has no role in OSGi, but it is nevertheless already used to provide non-normative information about the framework; for example all three of the major frameworks contain Export-Package headers in their manifests, and Bndtools exploits that information for pre-resolution. Neil On Tue, May 28, 2013 at 2:33 PM, David Bosschaert < [email protected]> wrote: > Thanks for the Reply Richard, I can create the Jiras if that helps... > > Cheers, > > David > > > On 28 May 2013 14:24, Richard S. Hall <[email protected]> wrote: > > > On 4/25/13 06:32 , David Bosschaert wrote: > > > >> On 24 April 2013 19:09, Richard S. Hall <[email protected]> wrote: > >> > >> On 4/24/13 14:05 , David Bosschaert wrote: > >>> > >>> On 23 April 2013 16:47, Richard S. Hall <[email protected]> wrote: > >>>> > >>>> On 4/23/13 10:54 , David Bosschaert wrote: > >>>> > >>>>> Forwarding to the Felix mailing list as well. AFAIK, Felix 4.2.1 > is a > >>>>> > >>>>>> core > >>>>>> R5 framework. At least it exports the org.osgi.framework in version > >>>>>> 1.7 > >>>>>> which tells me it's R5. > >>>>>> > >>>>>> It exports the R5 API, but it doesn't claim to fully implement the > >>>>>> R5 > >>>>>> > >>>>> API. > >>>>> We moved to the R5 API as a means to make it easier for people to > >>>>> submit > >>>>> patches to implement missing R5 features and to allow us to run the > OBR > >>>>> resolver. > >>>>> > >>>>> -> richard > >>>>> > >>>>> Is there a list of things that need to be done in order to get to > >>>> Core R5 > >>>> > >>>> support? Something like a list of JIRAs or something like that? > >>>> This might be useful for people who may want to help out getting > >>>> there... > >>>> > >>>> Yeah, that would be good. I could look into creating some issues, but > >>> if > >>> you want to do it, feel free. > >>> > >>> -> richard > >>> > >>> Let's first see what was introduced in Core R5. After looking at the > >>> 4.3/5 > >>> > >> specs a little I think the following is new in R5 (I might have missed > >> something though): > >> > >> * New org.osgi.framework.**UnfilteredServiceListener interface > >> > > > > Not implemented. > > > > * New org.osgi.framework.**VersionRange class > >> > > > > I would assume the class is there, since it is part of the API. Not sure > > if there was anything else necessary. > > > > > > * The Resource API and it's use in the Wiring API > >> > > > > I would guess most of that stuff would be in there since the framework > had > > to move to the new API. > > > > * New osgi.identity namespace > >> > > > > Not implemented, should be easy to add. > > > > > > * New value and new default for org.osgi.framework.bsnversion framework > >> property > >> > > > > Not implemented. > > > > > > * support for static valueOf methods in the Filter > >> > > > > Not implemented. > > > > > > * Enhanced Bundle.adapt() to support AccessControlContext > >> > > > > I don't think this is implemented. > > > > > > * Updates to the Bundle Hook Specification (Bundle Collision Hook) > >> > > > > Not implemented. > > > > > > > >> Richard maybe you can look at which of the above are supported in Felix > >> and > >> create JIRAs for the missing ones? > >> > > > > All of this is off the top of my head. I will create JIRA issues when I > > find the time...otherwise, feel free. > > > > -> richard > > > > > >> Cheers, > >> > >> David > >> > >> > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org< > [email protected]> > > For additional commands, e-mail: [email protected] > > > > >
