felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Handling of provisional OSGi API
Date Thu, 23 Sep 2010 15:34:16 GMT
  On 9/23/10 11:27, Guillaume Nodet wrote:
> I don't want to be the devil's advocate, but i think if the spec
> aren't published, we can't even make then available to the public in
> any form.
> I know that because the equinox guys, when working on a prototype for
> rfc 138 did not even include it it the svn tree.  So you had to grab
> them from the osgi repository and add them yourself to the build tree.
>    I know that's really annoying, but maybe we could discuss that with
> the OSGi alliance.

This is not what I understand. They've made 138 available already, I 
believe WebSphere depends on a prior prototype of 138. What both BJ and 
Tom told me is that they mark everything as deprecated.

The main thing I think we should avoid is including provisional OSGi API 
in our "official" releases, because this can clearly lead to confusion 
as to whether or not the OSGi API is also official.

However, I'm fine with Felix' view that we should always use our own 
namespace until the spec is final.

-> richard

> On Thu, Sep 23, 2010 at 16:13, Felix Meschberger<fmeschbe@gmail.com>  wrote:
>> Hi,
>>
>> Am 23.09.2010 16:05, schrieb Richard S. Hall:
>>>   On 9/23/10 2:49, Felix Meschberger wrote:
>>>> Hi,
>>>>
>>>> Maybe too late, but anyways.
>>> No, it's not too late, since we still need to define our policy with
>>> respect to provisional OSGi APIs...so we need everyone's opinion on this
>>> to come to consensus.
>>>
>>> Felix, this will likely impact you in odd ways if you continue to
>>> provide the Config Admin RI. For example, if you implement the future
>>> spec changes, if you plan to release it so people can play with it then
>>> you'll need to put the changed API in org.apache.felix.cm namespace.
>> Hmm, yes.
>>
>> Unless OSGi decides otherwise I am fine with continuing supplying the RI.
>>
>>> If you don't plan on releasing it until the spec is final, then I
>>> suppose org.osgi namespace is fine, but we should still probably mark
>>> them the same way.
>> Actually we should do this regardless of whether we release or not, but
>> maybe it would be good to release.
>>
>>> I guess this last point is also worthwhile to discuss. I think our
>>> policy can differentiate between what we release and what we experiment
>>> with, right? The policy for releases should be "no provisional OSGi
>>> API", while for playing around in trunk or a sandbox is different,
>>> right? Or no?
>> I think whatever we have in SVN is kind of publicly available and thus I
>> think we should do experiments in our own namespace even if we don't
>> release.
>>
>> Regards
>> Felix
>>
>>>> I am probably fine with #3.
>>>>
>>>> I particularly like the key argument for using mandatory attributes:
>>>> "clearly state that you know what you are doing".
>>> Ok, that's two for #3. :-)
>>>
>>> ->  richard
>>>
>>>> Regards
>>>> Felix
>>>>
>>>> Am 22.09.2010 21:48, schrieb Richard S. Hall:
>>>>>    On 9/22/10 14:44, Richard S. Hall wrote:
>>>>>>    Hopefully, I can get some quick feedback on this since I want
to do a
>>>>>> release...
>>>>>>
>>>>>> Guillaume and I were discussing alternatives to a mandatory attribute.
>>>>>> An alternative idea was mark all provisional API as deprecated, so
>>>>>> clients get warnings. What are people's thoughts on the two approaches?
>>>>>>
>>>>>>     1. The benefit of using mandatory attributes on provisional API
is
>>>>>>        that you have to explicitly "opt in" to use it so no one can
ever
>>>>>>        claim they didn't know it was provisional.
>>>>>>     2. The benefit of using deprecated tags is that it works more
>>>>>>        smoothly with tooling and at still does give some sort of
warning
>>>>>>        notice, although less direct.
>>>>>>
>>>>>> Personally, i still favor using mandatory attributes, because I think
>>>>>> it better captures our use case. But, I'd like to hear what other
>>>>>> people think.
>>>>> Tom Watson (of Equinox fame) pointed out that using both is probably
the
>>>>> best option because only using mandatory attributes doesn't address
>>>>> Require-Bundle, which could use the packages freely without opting in.
>>>>> Otherwise, he feels the same way I do, that mandatory attributes are
a
>>>>> good idea (just like for split packages), because you really need to
>>>>> know what you are doing to use the packages...
>>>>>
>>>>> Given the fact that I really need to get a release of Gogo trunk out
the
>>>>> door, I'm just going to push forward for now with what we have in trunk,
>>>>> which is using mandatory attributes. We can continue to refine our
>>>>> policy and when we are done, we can do another release to reflect it
>>>>> even if it means doing another one next week.
>>>>>
>>>>> So, to summarize, we now have three options:
>>>>>
>>>>>     1. Just mandatory attributes.
>>>>>     2. Just deprecated tags.
>>>>>     3. Both.
>>>>>
>>>>> After Tom's arguments, I'm probably now leaning toward #3.
>>>>>
>>>>> ->    richard
>>>>>
>>>>>> Quickly. :-)
>>>>>>
>>>>>> ->    richard
>>>>>>
>>>>>>
>>>>>> On 9/22/10 9:19, Richard S. Hall wrote:
>>>>>>>    On 9/22/10 6:16, Guillaume Nodet wrote:
>>>>>>>> I'm also not convinced by the mandatory attribute.  I do
understand
>>>>>>>> the value, but it may cause a lot of burden on our users
for not
>>>>>>>> much.
>>>>>>> If you have another recommendation for making it 100% clear to
our
>>>>>>> users that these packages will not be supported in the future,
then
>>>>>>> speak up. It's not that I want to use mandatory attributes, it's
that
>>>>>>> I don't want to be taken to task in the future for throwing away
the
>>>>>>> API. In that regard, I think there is benefit to using it since
>>>>>>> people have to go out of their way to use it.
>>>>>>>
>>>>>>> Regarding the version number, I was using 0.6.1 because it is
only a
>>>>>>> maintenance release as compared to 0.6.0. The completely incompatible
>>>>>>> change was from 0.4.0 to 0.6.0, no? Or are you specifically referring
>>>>>>> to the mandatory attribute? If so, I don't have an issue with
it
>>>>>>> being 0.8.0 if you think the mandatory attribute warrants it,
but I
>>>>>>> don't really think that constitutes a breaking code
>>>>>>> change...certainly a breaking metadata change.
>>>>>>>
>>>>>>> ->    richard
>>>>>>>
>>>>>>>>     Mandatory attributes are not very common and the tooling
might
>>>>>>>> not be
>>>>>>>> prepared to handle those gracefully.  For example, I've just
hit a
>>>>>>>> big
>>>>>>>> problem with karaf integration tests that use pax-exam, because
the
>>>>>>>> mandatory attribute it not automatically added, so all test
bundles
>>>>>>>> were failing during resolution ...
>>>>>>>> I've fixed that, but an average user will be in a real trouble
if
>>>>>>>> hitting this.
>>>>>>>>
>>>>>>>> On Wed, Sep 22, 2010 at 08:29, Guillaume Nodet<gnodet@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Do you plan to release gogo as 0.6.1 as indicated in
JIRA ?
>>>>>>>>> Given the change is fully incompatible, I'd at least
bump the minor
>>>>>>>>> version ...
>>>>>>>>>
>>>>>>>>> On Mon, Sep 20, 2010 at 17:50, Richard S.
>>>>>>>>> Hall<heavy@ungoverned.org>     wrote:
>>>>>>>>>>     On 9/20/10 11:21, Derek Baum wrote:
>>>>>>>>>>> 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
>>>>>>>>>>> vote?
>>>>>>>>>> It sounds like we have consensus, so we can probably
just move
>>>>>>>>>> forward.
>>>>>>>>>>
>>>>>>>>>> ->     richard
>>>>>>>>>>
>>>>>>>>>>> Derek
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>
>

Mime
View raw message