[
https://issues.apache.org/jira/browse/OAK-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-10252:
---------------------------------
Labels: candidate_oak_1_22 (was: )
> Distinguish in oak-jackrabbit-api between provider and consumer type
> interfaces
> -------------------------------------------------------------------------------
>
> Key: OAK-10252
> URL: https://issues.apache.org/jira/browse/OAK-10252
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jackrabbit-api
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> Priority: Major
> Labels: candidate_oak_1_22
> Fix For: 1.54.0
>
>
> Currently there is almost no annotation related to Provider or Consumer type
> maintained on the interfaces of
> https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api.
> That leads to a default of almost all interfaces being assumed ConsumerType
> and therefore requiring all backwards-incompatible changes (for
> implementations) a major version increment (which breaks every consuming
> bundle).
> For ProviderType interfaces
> (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html)
> bq. A non-binary-compatible change to a provider type normally requires
> incrementing the major version of the type's package. This change will
> require all providers and all consumers to be updated to handle the change.
> However, a non-binary-compatible change affecting a protected access member
> only requires incrementing the minor version of the type's package. This
> change will require all providers to be updated to handle the change, but
> consumers will not require changes since they only use, and do not extend,
> the provider type and thus could not access protected access members of the
> provider type.
> While for ConsumerType interfaces (the default)
> (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ConsumerType.html)
> bq. A non-binary-compatible change to a consumer type or a binary-compatible
> change to a consumer type affecting an abstract method normally requires
> incrementing the major version of the type's package. This change will
> require all providers and all consumers to be updated to handle the change
> since consumers that implement or extend the consumer type and all providers
> must understand the change in the consumer type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
