[
https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767265#comment-16767265
]
Thomas Watson commented on FELIX-6056:
--------------------------------------
I have a PR at: https://github.com/apache/felix/pull/183
Not sure why the magic linking in jira isn't happening for it. I've reverted
the dependencies back to 1.0 versions of promises and function because the
implementation of SCR doesn't need the latest. I've removed the exports and
the explicit imports so that BND will calculate the imports and range. This
results in only promises getting imported at range [1.0,2.0) which I think is
good.
I had to update the integration test to configure pax to install the promises
and function bundles. I will merge to trunk if I don't hear any objections
today (we can always revert if needed).
> 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)
