Re: Core and Compendium APIS at runtime

2015-05-26 Thread Jean-Baptiste Onofré
IMHO spec is enough. RegardsJB  Sent from my Samsung device Original message From: Christian Schneider Date: 26/05/2015 07:40 (GMT+01:00) To: users@felix.apache.org Subject: Re: Core and Compendium APIS at runtime Do you also have best practices for clients? I

Re: Core and Compendium APIS at runtime

2015-05-26 Thread Christian Schneider
Do you also have best practices for clients? I think in most cases it makes sense that a client just imports a the spec package. What about the case where a client optionally depends on a spec package? One case I saw several times was an optional dependency on the event admin. The problem wi

Re: Core and Compendium APIS at runtime

2015-05-25 Thread Raymond Auge
Is RSA a special case then? - Ray On Mon, May 25, 2015 at 9:50 AM, Richard S. Hall wrote: > Overall, I agree...we should probably add some of this argumentation to > our FAQ entry... > > -> richard > > > On 5/25/15 03:38 , Peter Kriens wrote: > >> This kind of reasoning is often caused by not s

Re: Core and Compendium APIS at runtime

2015-05-25 Thread Richard S. Hall
Overall, I agree...we should probably add some of this argumentation to our FAQ entry... -> richard On 5/25/15 03:38 , Peter Kriens wrote: This kind of reasoning is often caused by not seeing the extremely tight relation between the provider of an API and that API itself. There is virtually

Re: Core and Compendium APIS at runtime

2015-05-25 Thread Peter Kriens
This kind of reasoning is often caused by not seeing the extremely tight relation between the provider of an API and that API itself. There is virtually no backward compatibility for providers, if the API changes, you need a new provider. Separating the provider from its API therefore just creat

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Richard S. Hall
On 5/20/15 14:42 , Milen Dyankov wrote: Now, if you are saying that the framework should somehow enforce that implementations never provide the service API and that only the "official" service API bundles can be used to provide those packages, then I'd say that this would go too far. No I didn

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Milen Dyankov
> > Now, if you are saying that the framework should somehow enforce that > implementations never provide the service API and that only the "official" > service API bundles can be used to provide those packages, then I'd say > that this would go too far. No I didn't meant to say that. Rather that

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Richard S. Hall
On 5/20/15 11:37 , Milen Dyankov wrote: Well I agree in general. My only point is that IMHO the one defining the API should also be the one providing it at runtime. Since OSGi alliance is defining a spec which describes a service API it should be the one providing the API bundle. And apparently

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Milen Dyankov
Well I agree in general. My only point is that IMHO the one defining the API should also be the one providing it at runtime. Since OSGi alliance is defining a spec which describes a service API it should be the one providing the API bundle. Vendors are still free to provide their own implementation

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Raymond Auge
A little bit of good news on this topic. For R6 you will find that the OSGi Alliance will release (including to Maven Central) complete (code, source, javadoc, pom), individually packaged, usable at runtime, companion code bundles for every single spec (including everything not modified during thi

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Richard S. Hall
On 5/20/15 05:15 , Milen Dyankov wrote: Thanks for your answer Richard! I am aware if the FAQ however what it basically tells you is "it depends" ;) Unfortunately, it does depend on your circumstances. There are very few cases in software engineering where you can say, "always do it like th

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Richard Hall
On 5/20/15 05:15 , Milen Dyankov wrote: > > Thanks for your answer Richard! > > I am aware if the FAQ however what it basically tells you is "it depends" > ;) Thus I was hoping for some more insides so I can better understand the > intentions and the situation with service APIs from OSGi specs as

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Milen Dyankov
Thanks for your answer Richard! I am aware if the FAQ however what it basically tells you is "it depends" ;) Thus I was hoping for some more insides so I can better understand the intentions and the situation with service APIs from OSGi specs as of today. So, if I understand your answer correctly

Re: Core and Compendium APIS at runtime

2015-05-17 Thread Richard S. Hall
On 5/17/15 12:57 , Milen Dyankov wrote: Hi, I recently stumbled upon something that makes me wonder about OSGI specs APIs. As Metatype was the one API that made me start thinking about the issue, I'll use it as an example but the question is about APIs in general. So while attempting to replace

Core and Compendium APIS at runtime

2015-05-17 Thread Milen Dyankov
Hi, I recently stumbled upon something that makes me wonder about OSGI specs APIs. As Metatype was the one API that made me start thinking about the issue, I'll use it as an example but the question is about APIs in general. So while attempting to replace Felix's Metatype with Equinox one, I rea