On 5/28/13 09:58 , Neil Bartlett wrote:
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.
It is not clear how this would be useful in general when the
implementation is a work in progress. Sure, it is easy as a boolean flag
indicating yeah or nay to a certain spec level, but how does it help in
a case where a spec level is only partially implemented?
-> richard
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
