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