+1
Good point !
Regards
JB
On 12/23/2016 05:54 PM, Raymond Auge wrote:
+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 <b...@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 <njbartl...@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.bosscha...@gmail.com
wrote:
Hi all,
On 23 December 2016 at 12:13, Jan Willem Janssen <
janwillem.jans...@luminis.eu <mailto:janwillem.jans...@luminis.eu>>
wrote:
On 23 Dec 2016, at 12:30, David Bosschaert <
david.bosscha...@gmail.com
wrote:
Hi Bram,
On 23 December 2016 at 11:02, Bram Pouwelse <b...@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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
