[
https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766042#comment-16766042
]
Peter Kriens commented on FELIX-6056:
-------------------------------------
Yes, the API dependency is unfortunate since very few bundles use this class
(let alone these rarely used methods). it is one of the few places where an
OSGi spec references another spec than the framework. We always tried to keep
these separate, which is imho good design. Not sure what happened here. The
cost of not letting these functions use Promises would have been negligent.
The reason they export functions as well is I assume that Promises needs
requires them. Another good reason not to export a package that is not yours.
> SCR exports promises
> --------------------
>
> Key: FELIX-6056
> URL: https://issues.apache.org/jira/browse/FELIX-6056
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Reporter: Peter Kriens
> Priority: Major
>
> Apache Felix SCR exports promises 1.0 as a convenience. However, since this
> package contains the implementation it is a +provider+. Originally, the
> import was correct for a provider, [1,1.1). however, last July it was
> increased to [1,2). This therefore against the semantic versioning
> specification that prescribes a minor import range when providing the
> implementation of an API.
> Exporting an package like Promises is not a good idea anyway. It is only a
> convenience, promises have nothing to do with SCR in itself and that will
> always back fire in the end. Even exporting it correctly causes unnecessary
> version constraints since the order of resolving cannot be controlled. So if
> you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or
> 1.1 and it creates nasty class spaces.
> It is inconvenient to make SCR depend on Promises. Personally I would not
> have used promises or would have included the package privately. (No API of
> SCR depends on Promises) Since SCR is such a crucial base component I
> strongly recommend to not export it from SCR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
