Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Jean-Baptiste Onofré]

+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  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 
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 

wrote:


Hi all,

On 23 December 2016 at 12:13, Jan Willem Janssen <
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 

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

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Richard S. Hall]

I'm not for changing the policy. The whole point behind the policy is 
that anything that we released is in some way blessed and lives forever. 
If we release packages in the OSGi namespace, they look official even 
potentially after the OSGi Alliance dumps an RFC (ala Gogo). There is no 
way for us to retract a release.


So, yes, it makes the process a little bit of a pain, but that was sort 
of the point, so we could make the status clear. Besides, using a 
temporary package name until a spec if final and then doing a global 
search/replace when it goes final isn't really that painful.


-> richard

On 12/23/16 05:29 , David Bosschaert wrote:

Hi all,

The Felix project has a policy to prevent any releases that contain
provisional, unreleased OSGi APIs [1].

Developing OSGi APIs generally takes a substantial amount of time. In OSGi
RFPs and RFCs are written. Reference Implementations are developed, often
in Open Source such as here at Felix. Conformance Testsuites are written
and the actual spec is written. Then the whole package is voted on a number
of times by the OSGi membership before the spec is published.

Especially when creating a new spec having the implementation used as
widely as possible is very useful for gathering feedback. OTOH the policy
at [1] stands a bit in the way of wider adoption. It requires everyone to
build their own bundles before they can use it or they have to depend on
published snapshots which can really be unstable. If people want to release
an early implementation the policy at [1] requires the OSGi packages to be
renamed, which essentially makes them unusable by early adopters since they
have to change all their imports in their Java source files to pick up the
renamed package name.

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. We should also add the
@Deprecated annotations and the mandatory 'provisional' attribute, but I
think in this case, where the exported API has a version of < 1.0 it could
be ok to not require the package rename.
This will allow users to use the API in their code based on stable Felix
artifacts, and as the API package does not change once at 1.0 they will not
have to change their source code to migrate from the
org.apache.felix.someapi to org.osgi.someapi. They will need to make
changes to the metadata for the import to work with the released 1.0
version but this is usually somewhere central in a build file...

Disclosure: I would like to release the Felix Converter [2] like this and
have already added the @Deprecate and 'provisional' mandatory attribute...

Thoughts anyone?

Best regards,

David

[1]
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
[2] https://svn.apache.org/repos/asf/felix/trunk/converter/converter

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Raymond Auge]

+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  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 
> 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  >
> > wrote:
> > >
> > > Hi all,
> > >
> > > On 23 December 2016 at 12:13, Jan Willem Janssen <
> > > 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 
> 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é* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance 

[jira] [Updated] (FELIX-5435) Service does not get loaded with updated properties that have been modified on file system after felix framework restart

[Alin Brici (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alin Brici updated FELIX-5435:
--
Attachment: FELIX_5435.patch

> Service does not get loaded with updated properties that have been modified 
> on file system after felix framework restart
> 
>
> Key: FELIX-5435
> URL: https://issues.apache.org/jira/browse/FELIX-5435
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin, Declarative Services (SCR)
>Affects Versions: configadmin-1.8.0, configadmin-1.8.8, 
> configadmin-1.8.12, scr-2.0.4, scr-2.0.6
> Environment: Java 1.7; Using Felix framework version 5.4.0. 
>Reporter: Alin Brici
>Priority: Blocker
> Attachments: FELIX_5435.patch
>
>
> In felix.scr 2.0.6, seeing an issue where a configuration for a particular 
> Service is not loaded. 
> We have one @Component(Componenent A) that offers one service, lets call this 
> Service A. 
> ComponenetA attributes are as follows: {noformat}(name="ServiceA", policy= 
> ConfigurationPolicy.REQUIRE, metatype=true, immediate=true) {noformat}
> ServiceA has a configuration that could look like this:
> {noformat}
> {
>   "name" : "ServiceA",
>   "description" : "Displays which version it has of ServiceB",
>   "versionRequired" : "1"
> }
> {noformat}
> We have a second @Component(Component B) that offers another service, lets 
> call that Service B. 
> The Component attributes for Component B are as follows: 
> {noformat}(name:"ServiceB", policy=ConfigurationPolicy.OPTIONAL, 
> metatype=true, immediate=true).{noformat}
> (I understand with immediate=true and ConfiguraitonPolicy.OPTIONAL, Service B 
> will be initialized without any configuration when it first gets started by 
> the framework, however if there is configuration for it on the file system, 
> Felix DS will reload Service B with what is on file system when it scans the 
> directory for ServiceB configuraiton). 
> Service B, has some properties in the configuraiton for it, that are used by 
> ServiceA if ServiceB has been loaded with configuration. For example say we 
> have a configuration for ServiceB that looks like this. 
> {noformat}
> {
>   "name" : "ServiceB",
>   "description" : "is used by ServiceA"
>   "version" : "1"
> }
> {noformat}
> Service A has a reference to Service B, as so:
> {noformat}
> @Reference(policy = ReferencePolicy.DYNAMIC)
> volatile ServiceB serviceB = null;
> For example if we have something like this for ComponentA/ServiceA, I will 
> keep the code short to illustrate the problem. 
>   @Component(name = "ServiceA",
> policy = ConfigurationPolicy.REQUIRE,
> metatype = true,
> description = "ComponentA with ServiceA",
> immediate = true)
>   @Service(value = {ServiceAInterface.class})
>   public class ServiceA implements ServiceAInterface {
>   private String version; 
>   private String description; 
>   private Json config = null;
>   // version requested by VersionB 
>   private String versionRequested;
>   @Reference(policy = ReferencePolicy.DYNAMIC)
>   volatile ServiceB serviceB;
>   @Activate
>   protected void activate(ComponentContext context) {
>   this.config = getConfigFromComponentContext(context);
>   this.description = config.get("description");
>   this.versionRequested = config.get("versionRequested");
>   // get the version that ServiceA config requests 
>   
> serviceB.getVersionAsStringAsync(versionRequested).thenOnResult(
>   this.version = versionFromServiceB; 
>   );
>   }
>   // @Deactivate method would go here
>   @override
>   public String getVersion() {
>   if (version != null) {
>   return version;
>   } else {
>   return "No Version has been set yet!";
>   }
>   }   
>   }
> {noformat}
> For the scenario where this problem exists we need a configuration for both 
> ServiceA and ServiceB. The configuration is stored on the file system in some 
> directory that felix watches to load changes as they occur. /tmp/felixConfig/ 
> ServiceA.json ServiceB.json.   
> Start up the Felix OSGi environment with the configuration and what I see is 
> that it works as expected. ServiceA waits until it has its @Refernce to 
> ServiceB satisfied before it attempts to activate as expected. Then if I made 
> a call to Servi

[jira] [Commented] (FELIX-5435) Service does not get loaded with updated properties that have been modified on file system after felix framework restart

[Alin Brici (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773228#comment-15773228
 ] 

Alin Brici commented on FELIX-5435:
---

[~djencks], I have made the modification in CA that would fix this issue. I add 
the configuration to the cache after it is not found in the cache because this 
is the behavior DS is depending on. This is the same behavior that 
getConfigurations() does. I believe this is the correct behavior, I also fixed 
the unit tests in there to reflect this change. 

I have read 
http://felix.apache.org/documentation/community/contributing-source-code.html 
and I am not a Felix committer yet, so I have attached the diff, it's also 
below. I would love to be on the review or create the review myself if I missed 
the instructions on how to go about that. 

{code}
Index: 
../org.apache.felix.configadmin-1.8.12/src/test/java/org/apache/felix/cm/impl/ConfigurationManagerTest.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- 
../org.apache.felix.configadmin-1.8.12/src/test/java/org/apache/felix/cm/impl/ConfigurationManagerTest.java
 (revision 1770905)
+++ 
../org.apache.felix.configadmin-1.8.12/src/test/java/org/apache/felix/cm/impl/ConfigurationManagerTest.java
 (revision )
@@ -95,12 +95,6 @@
 assertEquals(1, conf.length);
 assertEquals(2, conf[0].getProperties(true).size());
 
-Field configurations = configMgr.getClass().getDeclaredField( 
"configurations" );
-configurations.setAccessible( true );
-HashMap configurationsMap = new 
HashMap();
-configurationsMap.put(pid, conf[0]);
-configurations.set(configMgr, configurationsMap);
-
 dictionary = new Hashtable();
 dictionary.put( "property1", "value2" );
 pid = "testDefaultPersistenceManager";
@@ -110,6 +104,9 @@
 conf = configMgr.listConfigurations(new 
ConfigurationAdminImpl(configMgr, null), null);
 assertEquals(1, conf.length);
 assertEquals(2, conf[0].getProperties(true).size());
+
+// verify that the property in the configurations cache was used
+assertEquals("value1", conf[0].getProperties(true).get("property1"));
 }
 
 public void test_listConfigurations_notcached() throws Exception
@@ -135,20 +132,18 @@
 assertEquals(1, conf.length);
 assertEquals(2, conf[0].getProperties(true).size());
 
-Field configurations = configMgr.getClass().getDeclaredField( 
"configurations" );
-configurations.setAccessible( true );
-HashMap configurationsMap = new 
HashMap();
-configurationsMap.put(pid, conf[0]);
-configurations.set(configMgr, configurationsMap);
-
 dictionary = new Hashtable();
+dictionary.put("property1", "valueNotCached");
 pid = "testDefaultPersistenceManager";
 dictionary.put( Constants.SERVICE_PID, pid );
 pm.store( pid, dictionary );
  
 conf = configMgr.listConfigurations(new 
ConfigurationAdminImpl(configMgr, null), null);
 assertEquals(1, conf.length);
-assertEquals(1, conf[0].getProperties(true).size());
+assertEquals(2, conf[0].getProperties(true).size());
+
+// verify that the value returned was not the one from the cache
+assertEquals("valueNotCached", 
conf[0].getProperties(true).get("property1"));
 }
 
 public void testLogNoLogService()
Index: 
../org.apache.felix.configadmin-1.8.12/src/main/java/org/apache/felix/cm/impl/ConfigurationManager.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- 
../org.apache.felix.configadmin-1.8.12/src/main/java/org/apache/felix/cm/impl/ConfigurationManager.java
 (revision 1770905)
+++ 
../org.apache.felix.configadmin-1.8.12/src/main/java/org/apache/felix/cm/impl/ConfigurationManager.java
 (revision )
@@ -683,14 +683,16 @@
 }
 
 // ensure the service.pid and returned a cached config if 
available
-ConfigurationImpl cfg = null;
-if (! (pmList[i].isNotCachablePersistenceManager())) 
-{
+ConfigurationImpl cfg;
+if (!(pmList[i].isNotCachablePersistenceManager())) {
 cfg = getCachedConfiguration( pid );
+if (cfg == null) {
+cfg = new ConfigurationImpl(this, pmList[i], config);
+// add the to configurations cache if it wasn't in the 
cache
+cacheConfiguration(cfg);
-}
+}
-if ( cfg == null )
-{
+} else {
-cfg = new 

[jira] [Updated] (FELIX-5435) Service does not get loaded with updated properties that have been modified on file system after felix framework restart

[Alin Brici (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alin Brici updated FELIX-5435:
--
Affects Version/s: configadmin-1.8.0
   configadmin-1.8.8
   configadmin-1.8.12

> Service does not get loaded with updated properties that have been modified 
> on file system after felix framework restart
> 
>
> Key: FELIX-5435
> URL: https://issues.apache.org/jira/browse/FELIX-5435
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin, Declarative Services (SCR)
>Affects Versions: configadmin-1.8.0, configadmin-1.8.8, 
> configadmin-1.8.12, scr-2.0.4, scr-2.0.6
> Environment: Java 1.7; Using Felix framework version 5.4.0. 
>Reporter: Alin Brici
>Priority: Blocker
>
> In felix.scr 2.0.6, seeing an issue where a configuration for a particular 
> Service is not loaded. 
> We have one @Component(Componenent A) that offers one service, lets call this 
> Service A. 
> ComponenetA attributes are as follows: {noformat}(name="ServiceA", policy= 
> ConfigurationPolicy.REQUIRE, metatype=true, immediate=true) {noformat}
> ServiceA has a configuration that could look like this:
> {noformat}
> {
>   "name" : "ServiceA",
>   "description" : "Displays which version it has of ServiceB",
>   "versionRequired" : "1"
> }
> {noformat}
> We have a second @Component(Component B) that offers another service, lets 
> call that Service B. 
> The Component attributes for Component B are as follows: 
> {noformat}(name:"ServiceB", policy=ConfigurationPolicy.OPTIONAL, 
> metatype=true, immediate=true).{noformat}
> (I understand with immediate=true and ConfiguraitonPolicy.OPTIONAL, Service B 
> will be initialized without any configuration when it first gets started by 
> the framework, however if there is configuration for it on the file system, 
> Felix DS will reload Service B with what is on file system when it scans the 
> directory for ServiceB configuraiton). 
> Service B, has some properties in the configuraiton for it, that are used by 
> ServiceA if ServiceB has been loaded with configuration. For example say we 
> have a configuration for ServiceB that looks like this. 
> {noformat}
> {
>   "name" : "ServiceB",
>   "description" : "is used by ServiceA"
>   "version" : "1"
> }
> {noformat}
> Service A has a reference to Service B, as so:
> {noformat}
> @Reference(policy = ReferencePolicy.DYNAMIC)
> volatile ServiceB serviceB = null;
> For example if we have something like this for ComponentA/ServiceA, I will 
> keep the code short to illustrate the problem. 
>   @Component(name = "ServiceA",
> policy = ConfigurationPolicy.REQUIRE,
> metatype = true,
> description = "ComponentA with ServiceA",
> immediate = true)
>   @Service(value = {ServiceAInterface.class})
>   public class ServiceA implements ServiceAInterface {
>   private String version; 
>   private String description; 
>   private Json config = null;
>   // version requested by VersionB 
>   private String versionRequested;
>   @Reference(policy = ReferencePolicy.DYNAMIC)
>   volatile ServiceB serviceB;
>   @Activate
>   protected void activate(ComponentContext context) {
>   this.config = getConfigFromComponentContext(context);
>   this.description = config.get("description");
>   this.versionRequested = config.get("versionRequested");
>   // get the version that ServiceA config requests 
>   
> serviceB.getVersionAsStringAsync(versionRequested).thenOnResult(
>   this.version = versionFromServiceB; 
>   );
>   }
>   // @Deactivate method would go here
>   @override
>   public String getVersion() {
>   if (version != null) {
>   return version;
>   } else {
>   return "No Version has been set yet!";
>   }
>   }   
>   }
> {noformat}
> For the scenario where this problem exists we need a configuration for both 
> ServiceA and ServiceB. The configuration is stored on the file system in some 
> directory that felix watches to load changes as they occur. /tmp/felixConfig/ 
> ServiceA.json ServiceB.json.   
> Start up the Felix OSGi environment with the configuration and what I see is 
> that it works as expected. ServiceA waits until it has its @Refernce to 
> ServiceB satisfied before it attempts to activa

Re: [RESULT] [VOTE] Release Felix shell.remote version 1.2.0

[Benson Margulies]

This vote passed with three binding +1 and no -1 votes.

On Mon, Dec 19, 2016 at 10:29 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Bram Pouwelse]

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  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 
> wrote:
> >
> > Hi all,
> >
> > On 23 December 2016 at 12:13, Jan Willem Janssen <
> > janwillem.jans...@luminis.eu >
> wrote:
> >
> >>
> >>> On 23 Dec 2016, at 12:30, David Bosschaert  >
> >> wrote:
> >>>
> >>> Hi Bram,
> >>>
> >>> On 23 December 2016 at 11:02, Bram Pouwelse  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
> >
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Jan Willem Janssen]

> On 23 Dec 2016, at 13:36, David Bosschaert  wrote:
> 
> Hi all,
> 
> On 23 December 2016 at 12:13, Jan Willem Janssen <
> janwillem.jans...@luminis.eu> wrote:
> 
>> 
>>> On 23 Dec 2016, at 12:30, David Bosschaert 
>> wrote:
>>> 
>>> Hi Bram,
>>> 
>>> On 23 December 2016 at 11:02, Bram Pouwelse  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.

Good compromise.

> Needless to say that these mandatory attributes will be removed once the
> OSGi API is released and at 1.0

You should want to do that anyways given that the API is no longer considered
provisional ;)

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814


My world is something with Amdatu and Apache

Luminis Technologies
Churchillplein 1
7314 BZ  Apeldoorn
+31 88 586 46 00

https://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Neil Bartlett]

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  wrote:
> 
> Hi all,
> 
> On 23 December 2016 at 12:13, Jan Willem Janssen <
> janwillem.jans...@luminis.eu > wrote:
> 
>> 
>>> On 23 Dec 2016, at 12:30, David Bosschaert 
>> wrote:
>>> 
>>> Hi Bram,
>>> 
>>> On 23 December 2016 at 11:02, Bram Pouwelse  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
>  
> 

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[David Bosschaert]

Hi all,

On 23 December 2016 at 12:13, Jan Willem Janssen <
janwillem.jans...@luminis.eu> wrote:

>
> > On 23 Dec 2016, at 12:30, David Bosschaert 
> wrote:
> >
> > Hi Bram,
> >
> > On 23 December 2016 at 11:02, Bram Pouwelse  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

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Jan Willem Janssen]

> On 23 Dec 2016, at 12:30, David Bosschaert  wrote:
> 
> Hi Bram,
> 
> On 23 December 2016 at 11:02, Bram Pouwelse  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.

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814


My world is something with Amdatu and Apache

Luminis Technologies
Churchillplein 1
7314 BZ  Apeldoorn
+31 88 586 46 00

https://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Bram Pouwelse]

In that case I don't like the idea of released bundles using API versions <
1. What if some other bundle is providing that same package there would be
no way for te resolver to know that those packages are actually not
compatible.

On Fri, Dec 23, 2016 at 12:30 PM David Bosschaert <
david.bosscha...@gmail.com> wrote:

> Hi Bram,
>
> On 23 December 2016 at 11:02, Bram Pouwelse  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...
>
> Cheers,
>
> David
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[David Bosschaert]

Hi Bram,

On 23 December 2016 at 11:02, Bram Pouwelse  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...

Cheers,

David

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[Bram Pouwelse]

> 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).

Also not sure how big the imports issue is, if the api is fully compatible
that would be a find /replace?

Regards,
Bram

On Fri, Dec 23, 2016 at 11:30 AM David Bosschaert <
david.bosscha...@gmail.com> wrote:

Hi all,

The Felix project has a policy to prevent any releases that contain
provisional, unreleased OSGi APIs [1].

Developing OSGi APIs generally takes a substantial amount of time. In OSGi
RFPs and RFCs are written. Reference Implementations are developed, often
in Open Source such as here at Felix. Conformance Testsuites are written
and the actual spec is written. Then the whole package is voted on a number
of times by the OSGi membership before the spec is published.

Especially when creating a new spec having the implementation used as
widely as possible is very useful for gathering feedback. OTOH the policy
at [1] stands a bit in the way of wider adoption. It requires everyone to
build their own bundles before they can use it or they have to depend on
published snapshots which can really be unstable. If people want to release
an early implementation the policy at [1] requires the OSGi packages to be
renamed, which essentially makes them unusable by early adopters since they
have to change all their imports in their Java source files to pick up the
renamed package name.

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. We should also add the
@Deprecated annotations and the mandatory 'provisional' attribute, but I
think in this case, where the exported API has a version of < 1.0 it could
be ok to not require the package rename.
This will allow users to use the API in their code based on stable Felix
artifacts, and as the API package does not change once at 1.0 they will not
have to change their source code to migrate from the
org.apache.felix.someapi to org.osgi.someapi. They will need to make
changes to the metadata for the import to work with the released 1.0
version but this is usually somewhere central in a build file...

Disclosure: I would like to release the Felix Converter [2] like this and
have already added the @Deprecate and 'provisional' mandatory attribute...

Thoughts anyone?

Best regards,

David

[1]
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
[2] https://svn.apache.org/repos/asf/felix/trunk/converter/converter

RE: [ANN] New Apache Felix Committer: Stefan Seifert

[Stefan Seifert]

thanks!

it is a tradition that a new committer introduces himself, so here are some 
words about myself:

i'm living in berlin, and using OSGi and Felix for about 7 years. i'm also 
heavily involved in the Apache Sling community where i'm committer since 2014. 
but my first relevant contribution to an Apache project was to Apache Felix in 
2009 (FELIX-1010). i'm also involved in organizing the yearly adaptTo() 
conference in berlin, which focuses on Apache Sling, Felix and Jackrabbit.

within Felix my main areas of interest in the past was the tooling part like 
Maven Bundle Plugin, SCR, Web Console.

stefan


>-Original Message-
>From: Carsten Ziegeler [mailto:cziege...@apache.org]
>Sent: Friday, December 23, 2016 11:28 AM
>To: dev@felix.apache.org
>Subject: [ANN] New Apache Felix Committer: Stefan Seifert
>
>Hi
>
>it's my pleasure to announce that the Apache Felix PMC has invited
>Stefan Seifert as a new Felix committer...and gladly Stefan accepted.
>
>So please join me in welcoming Stefan.
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org

Proposal for slight amendment to Felix provisional OSGi API policy

[David Bosschaert]

Hi all,

The Felix project has a policy to prevent any releases that contain
provisional, unreleased OSGi APIs [1].

Developing OSGi APIs generally takes a substantial amount of time. In OSGi
RFPs and RFCs are written. Reference Implementations are developed, often
in Open Source such as here at Felix. Conformance Testsuites are written
and the actual spec is written. Then the whole package is voted on a number
of times by the OSGi membership before the spec is published.

Especially when creating a new spec having the implementation used as
widely as possible is very useful for gathering feedback. OTOH the policy
at [1] stands a bit in the way of wider adoption. It requires everyone to
build their own bundles before they can use it or they have to depend on
published snapshots which can really be unstable. If people want to release
an early implementation the policy at [1] requires the OSGi packages to be
renamed, which essentially makes them unusable by early adopters since they
have to change all their imports in their Java source files to pick up the
renamed package name.

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. We should also add the
@Deprecated annotations and the mandatory 'provisional' attribute, but I
think in this case, where the exported API has a version of < 1.0 it could
be ok to not require the package rename.
This will allow users to use the API in their code based on stable Felix
artifacts, and as the API package does not change once at 1.0 they will not
have to change their source code to migrate from the
org.apache.felix.someapi to org.osgi.someapi. They will need to make
changes to the metadata for the import to work with the released 1.0
version but this is usually somewhere central in a build file...

Disclosure: I would like to release the Felix Converter [2] like this and
have already added the @Deprecate and 'provisional' mandatory attribute...

Thoughts anyone?

Best regards,

David

[1]
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
[2] https://svn.apache.org/repos/asf/felix/trunk/converter/converter

[ANN] New Apache Felix Committer: Stefan Seifert

[Carsten Ziegeler]

Hi

it's my pleasure to announce that the Apache Felix PMC has invited
Stefan Seifert as a new Felix committer...and gladly Stefan accepted.

So please join me in welcoming Stefan.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org