felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Derek Baum <derek.b...@paremus.com>
Subject Re: Handling of provisional OSGi API
Date Mon, 20 Sep 2010 15:21:59 GMT
I also favor #1.

When we apply this to gogo, it will mean removing the draft RFC-147 API from
the org.osgi.service.command namespace and moving it to a felix namespace.

We actually already did this for the gogo-0.6 release, but then reverted the
change in the trunk, as it broke many command providers who imported
org.osgi.service.command. Back then we didn't have a policy for supporting
draft OSGi APIs, but now it seems like we've agreed on #1. Do we need a


On 19 September 2010 17:27, Richard S. Hall <heavy@ungoverned.org> wrote:

>  On 9/18/10 10:34, Felix Meschberger wrote:
>> Hi,
>> While I understand (and certainly don't underestimate the consequences
>> of) the drawbacks of option (1) I still think it is the better option.
>> At the time the OSGi releases the official API, we can still keep our
>> internal API for certain period of time thus supporting both API, if we
>> so wish.
> From my point of view we should just export the packages with mandatory
> attributes and make it clear they will change when the API goes final. For
> framework, I wouldn't plan to provide any ongoing support for provisional
> API. However, I don't think we need to mandate a global Felix policy for
> this and subprojects can choose to support two APIs if they want.
> -> richard
>  Regards
>> Felix
>> Am 17.09.2010 18:35, schrieb Richard S. Hall:
>>>  For a long time, we've played a little fast and loose with our handling
>>> of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
>>> releases, we've started to evolve a policy on how to handle this, but
>>> nothing has been decided concretely. This is problematic since it leads
>>> different people to different decisions. Thus, its about time we defined
>>> our policy on this.
>>> So, what's the issue?
>>> Provisional OSGi API is not official. Further, provisional package
>>> content is evolving and these changes are not always made readily
>>> available by the OSGi Alliance. Even though some of us are members of
>>> the OSGi Alliance, we are not necessarily at liberty to disclose changes
>>> to internal RFCs.
>>> So, what can we do about it?
>>> I see two potential [reasonable] policies from which we could choose:
>>>   1. Always use the org.apache.felix package namespace for provisional
>>>      OSGi API until the spec goes final.
>>>   2. Use the org.osgi package namespace while the provisional API is in
>>>      development, but only expose what has been publicly made available
>>>      by the OSGi Alliance.
>>> Both approaches have their drawbacks.
>>> The benefit of (1) is that the legal/IP/etiquette issues and/or concerns
>>> are reduced to those associated with normal open source development. For
>>> completely new development, like Gogo, this would all happen in non-OSGi
>>> packages, while changes to existing packages would need to be done in
>>> subclasses in non-OSGi packages. One downside of (1) is that it will
>>> always result in a package name change at the end that will break
>>> existing clients. For this reason, such experimental packages should be
>>> exported with mandatory attributes to warn potential clients.
>>> The benefit of (2) is that the package namespace is more consistent. The
>>> downside of (2) is that it is a IP/legal/etiquette gray area as to
>>> whether or not we can do official releases of subprojects containing
>>> provisional OSGi API. Even if we do not modify the API, it still is
>>> potentially confusing to our users who are getting an "official" release
>>> from us of a subproject containing these "unofficial" bytes. At a
>>> minimum we would also need to use deprecated tags and/or mandatory
>>> attributes to warn people. Even then, it still raises issues since we
>>> aren't at liberty to evolve the packages freely to include OSGi
>>> internal, non-public RFC updates, nor extensions for potential feedback
>>> into the RFC. In those cases, we would still need to resort to putting
>>> stuff in org.apache.felix packages and renaming later once the changes
>>> become public, which would also be problematic for clients. Also, you
>>> have to consider the case where the RFC is abandoned, in which case if
>>> we still find it useful, we'll be forced to change our package names.
>>>  From my point of view, approach (1) might not be awesome, but it results
>>> in a simpler process than (2). So, I'd recommend (1). If the majority
>>> prefers (2), then we can do that (although I think we'll have to run the
>>> decision by the board first).
>>> Thoughts?
>>> ->  richard

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message