On Wed, Oct 16, 2019 at 7:53 PM Greg Amerson via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
> And with regards to version increases, if a new method added to
> `DataHandler` that would break API and cause a major version increase for
> the package, however, if a new method was added to `DataContext` since that
> API is marked `@ProviderType` the package version increase would only have
> to be minor. Is that correct?
>
That is correct!
- Ray
>
> On Wed, Oct 16, 2019 at 6:06 PM Raymond Auge via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Let me see if I can take a crack at it! Though I'm often told I also
>> don't understand when I try to explain it. :D
>>
>> Suppose you have an API like so:
>>
>> interface DataHandler {
>> void processData(DataContext context);
>> }
>>
>> This API has 2 interfaces `DataHandler` and `DataContext`
>>
>> Now you happen to know there is a library data.machine-1.2.3.jar which is
>> a data processing engine and to use it all you need to do is publish an
>> OSGi service of type `DataHandler` and it will do some magic.
>>
>> Since you implement `DataHandler` this interface is sensitive to you as a
>> consumer. If the API were to add a method if would break your code. In this
>> case DataHandler is effectively @ConsumerType. It is a type which is
>> implemented in order to _use_ the API.
>>
>> Now, DataContext is not so sensitive for you in this scenario because you
>> only _recieve_ instances of it. You never have to implement it in your
>> _use_ of the API. In this case DataContext is @ProviderType since it's an
>> interface which only _providers_ implement. Therefore if a new method was
>> added to it, it would _not_ break your code, it _would_ however force the
>> implementers of data.machine-1.2.3.jar to make a new release since they are
>> a _provider_ of the API.
>>
>> So you see, both interfaces are part of the same API, yet one is
>> @ConsumerType (DataHandler) and the other is @ProviderType (DataContext).
>>
>> I hope that helps. Others feel free to correct my understanding and
>> hopefully, I'll finally grok it myself.
>> - Ray
>>
>>
>> On Wed, Oct 16, 2019 at 3:34 PM Milen Dyankov via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Welcome to the club ;) I struggled with that myself for a long time.
>>>
>>> I think I finally got to understand it couple of years ago. Here is how
>>> I explained it during one of my talks:
>>> https://www.youtube.com/watch?v=hGNrZmr0zz8&feature=youtu.be&t=1569
>>> I hope this helps better than me trying to write it all down here.
>>>
>>> Best,
>>> Milen
>>>
>>> On Wed, Oct 16, 2019 at 9:15 PM Leschke, Scott via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
>>>> I’m trying to wrap my head around these two annotations and I’m
>>>> struggling a bit. Is the perspective of the provider and consumer roles
>>>> from a bundle perspective or an application perspective?
>>>>
>>>> I’ve read the Semantic Versioning whitepaper a number of times and it
>>>> doesn’t really clear things up for me definitely.
>>>>
>>>>
>>>>
>>>> If an application has an API bundle that only exposes Interfaces and
>>>> Abstract classes, and those interfaces are implemented by other bundles in
>>>> the app, are those bundles providers or consumers? My inclination is that
>>>> they’re providers but then when does a bundle become a consumer? Given
>>>> that API bundles are compile only (this is the rule right?), would a good
>>>> rule be that if you implement the interface and export the package it’s in,
>>>> that type would be @ProviderType, if you don’t implement it it’s
>>>> @ConsumeType?
>>>>
>>>>
>>>>
>>>> It would seem to me that @ProviderType would be the default using this
>>>> logic, as opposed to @ConsumerType, which leads me to believe that I’m
>>>> thinking about this wrong.
>>>>
>>>>
>>>>
>>>> Any help appreciated as always.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> Scott Leschke
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>>
>>> --
>>> http://about.me/milen
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>> (@Liferay)
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc. www.liferay.com
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
