You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Konrad Windszus (Jira)" <ji...@apache.org> on 2023/05/19 16:11:00 UTC

[jira] [Created] (OAK-10252) Distinguish in oak-jackrabbit-api between provider and consumer type interfaces

Konrad Windszus created OAK-10252:
-------------------------------------

             Summary: 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


Currently there is 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 all interfaces being assumed ConsumerType and therefore requiring all backwards-incompatible changes 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)