felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: Proposal for slight amendment to Felix provisional OSGi API policy
Date Fri, 23 Dec 2016 16:54:42 GMT
+1

I'd really like this support as well. As an RI writer the prospect of
having to use a different package name during the API development process
is not appealing at all.

- Ray

On Fri, Dec 23, 2016 at 8:01 AM, Bram Pouwelse <bram@pouwelse.com> wrote:

> I Like the simple version ( org.osgi.someapi; version="0.1";
> mandatory:="provisional"; provisional="felix" ), and then I think it makes
> sense to advise a bit more conservative import range like
>  Import-Package: org.osgi.someapi;version="[0.1,0.2)";provisional=felix
>
> And that also implies that the version needs to be updated when a newer
> version is included in a next version.
>
>
> On Fri, Dec 23, 2016 at 1:41 PM Neil Bartlett <njbartlett@gmail.com>
> wrote:
>
> > This suggestion from David sounds like a reasonable compromise to me.
> >
> > I would point out that if you are building with bnd and you put a bundle
> > with a mandatory attribute on your build path, then bnd will assume that
> > you want to set that attribute on your import. Thus it will work fairly
> > transparently. And of course if you DON’T want provisional APIs, don’t
> put
> > provisional bundles on your build path. As the developer this is
> something
> > that you will have full control over.
> >
> > Neil
> >
> > > On 23 Dec 2016, at 12:36, David Bosschaert <david.bosschaert@gmail.com
> >
> > wrote:
> > >
> > > Hi all,
> > >
> > > On 23 December 2016 at 12:13, Jan Willem Janssen <
> > > janwillem.janssen@luminis.eu <mailto:janwillem.janssen@luminis.eu>>
> > wrote:
> > >
> > >>
> > >>> On 23 Dec 2016, at 12:30, David Bosschaert <
> david.bosschaert@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>> Hi Bram,
> > >>>
> > >>> On 23 December 2016 at 11:02, Bram Pouwelse <bram@pouwelse.com>
> wrote:
> > >>>
> > >>>>> I think it would be nice if we could relax the policy at [1]
a
> little
> > >> bit
> > >>>> and say that it is ok to release bundles with provisional API in
> > >> versions <
> > >>>> 1.0. The OSGi APIs always start their versions at 1.0 so an API
> > version
> > >> 0.2
> > >>>> will never conflict with an OSGi released API.
> > >>>>
> > >>>> That sounds nice but you can't have major changes in the provisional
> > API
> > >>>> (or you'd loose semantic versioning).
> > >>>>
> > >>>>
> > >>> There is a somewhat unwritten convention that API < 1.0 is
> > 'experimental'
> > >>> and therefore that exported API in versions [0.0, 1.0) does not
> follow
> > >>> semantic versioning... Basically what you're signing up to by using
> > this
> > >>> 'provisional' API which has a version < 1.0 is that anything could
> > >> change…
> > >>
> > >> Why not go for the empty version of 0.0.0 for such APIs then? I
> > understand
> > >> that there’s a need to express the fact that an API is still actively
> > being
> > >> developed and not yet final, but using versions in the range of [0,1)
> > would
> > >> make stuff just more complex given that they loose all semantics and
> are
> > >> only “informational” for humans to parse and comprehend.
> > >>
> > >>
> > > Whether we stick with 0.0.0 or allow different versions between [0.0.0,
> > > 1.0) this would still suffer from Bram's point that if multiple
> projects
> > do
> > > releases that contain provisional API you don't know which one you'll
> get
> > > from the resolver.
> > >
> > > This could be fixed by using mandatory attributes on the exported
> > package.
> > > It is a somewhat rarely used feature of OSGi. Currently the document at
> > [1]
> > > says to use the following decoration on the exported package:
> > >  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
> > > status="provisional"
> > >
> > > This means that importers can only import this package if they
> expressly
> > > add this to the import:
> > >  Import-Package: ,org.osgi.someapi;version="[0.
> 0,1)";status="provisional"
> > >
> > > We could specialize this a little bit to indicate what project the
> > version
> > > is from
> > >  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
> > > status="provisional"; implementation="felix"
> > > or maybe simply:
> > >  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
> > > ="felix"
> > >
> > > Then the import would become:
> > >  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
> > > which means that the import will only resolve to the 'felix' variant of
> > the
> > > provisional API. So from a resolution point of view the ambiguity is
> gone
> > > then.
> > >
> > > Needless to say that these mandatory attributes will be removed once
> the
> > > OSGi API is released and at 1.0
> > >
> > > Cheers,
> > >
> > > David
> > >
> > > [1]
> > >
> > http://felix.apache.org/documentation/development/
> provisional-osgi-api-policy.html
> > <
> > http://felix.apache.org/documentation/development/
> provisional-osgi-api-policy.html
> > >
> >
>



-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

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