Hi, sorry for the confusion here, I think I may be just wrong. From the standard policies from Bnd I do no longer think mixing Consumer and Provider in one package can lead to breaking users of the API more easily.
Let's quickly recall what the rules are: Rules for Exported Versions ==== ConsumerType Every binary incompatible change requires an increment on the major version. ProviderType Every binary incompatible change requires (at least) an increment on the minor version. Rules for Imported Versions ===== For each interface/ non final class it is stated, whether it is supported to be implemented/extended by Consumers (and providers, the default) or by Providers only. That information together with the information whether the interface is just used or really implemented determines the version-range of the import-package statement: Annotation on class/interface | Version Implemented | Import-Package Version Range | Versioning Policy @ConsumerType 1.1.0 yes [1.1, 2.0) Consumer @ConsumerType 1.1.0 no [1.1, 2.0) Consumer @ProviderType 1.1.0 yes [1.1, 1.2) Provider @ProviderType 1.1.0 no [1.1, 2.0) Consumer Those policies can be overwritten via the instruction http://bnd.bndtools.org/instructions/consumer_policy.html and http://bnd.bndtools.org/instructions/provider_policy.html. From those rules I cannot construct a usage which would point at splitting Consumer and Provider types. I think my confusion initially came from https://github.com/apache/felix-dev/blob/057bb85d7d496671755cd53cffc9e91a17c1d17c/tools/osgicheck-maven-plugin/src/main/java/org/apache/felix/maven/osgicheck/impl/checks/ConsumerProviderTypeCheck.java#L115 @Carsten: Do you remember why that usage leads to an error in osgicheck-maven-plugin? Konrad > On 29. Jun 2021, at 20:23, Eric Norman <[email protected]> wrote: > > I haven't looked at this too closely, but do you think that there could be > some benefit to keeping them in separate packages if you expect the > consumer and provider apis to evolve at a different pace? > > If I recall correctly, the bundles that import and use stuff from a package > that contains both consumer and provider classes may get a too specific > range for the import package range. > This has to do with bndlib choosing the "provider-policy" instead of the > "consumer-policy" when calculating the version ranges. > > From what I read, the default definitions for bnd are: > > -consumer-policy ${range;[==,+)} > -provider-policy ${range;[==,=+)} > > > > Specifically, the import-package item can end up with a narrow range as > something like org.apache.sling.whatever; version="[2.4, 2.5)" for the > importing bundles which can leads to troubles when the next minor change > requires the exported package to get bumped to "2.5.0" since that exported > package number no longer satisfies the import package range. This would > mean that all the "importing" bundles would have to change as well and you > end up with a cascade of new releases just for some minor change in the > "consumer" part of the exported package even if the changes were trivial > and backward compatible. > > Regards, > -Eric > > > > On Tue, Jun 29, 2021 at 8:54 AM Carsten Ziegeler <[email protected]> > wrote: > >> I don't think that not mixing consumer and provider interfaces is a best >> practice. >> >> The OSGi specs - which I think are usually following best practices - >> are mixing them. For example event admin where the event admin interface >> is in the same package as the event handler. >> >> The markers actually help putting those interfaces into the same >> package. In above example you can change the event admin interface >> without breaking the event handler. >> >> The framework api does the same, confgig admin etc. >> >> It's good to split packages based on purpose and usage. For example to >> move SPI interfaces into a separate package. >> >> Regards >> Carsten >> >> Am 29.06.2021 um 16:49 schrieb Bertrand Delacretaz: >>> Hi Konrad, >>> >>> On Tue, Jun 29, 2021 at 3:04 PM Konrad Windszus <[email protected]> wrote: >>>> - Please don't mix Consumer and Provider interfaces in the same package >>>> ( >> https://github.com/apache/sling-org-apache-sling-sitemap/tree/master/src/main/java/org/apache/sling/sitemap/generator >>>> and >>>> >> https://github.com/apache/sling-org-apache-sling-sitemap/tree/master/src/main/java/org/apache/sling/sitemap/builder/extensions >> ) >>>> as that enforces updates to break more consumers than necessary.... >>> >>> Could you elaborate on that? The issue is not obvious to me. >>> >>> More generally, I think it would be useful for us to document best >>> practices around Consumer and Provider interfaces. >>> >>> If someone has links to such best practices that would be great, >>> otherwise feel free to add some notes in response to this message and >>> I'll write something up for https://sling.apache.org/ >>> >>> -Bertrand >>> >> >> -- >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] >>
