[
https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767079#comment-16767079
]
Carsten Ziegeler commented on FELIX-6056:
-----------------------------------------
Yes, I agree that we shouldn't have used Promises in the SCR Runtime API and
its also a problem that promises has both API and impl in the same package.
I think we've updated to R7 promises now.
I'm still not 100% convinced about this, but in the end it's not important
enough to spend too much time on it. It seems the current situation is causing
problems, so let's change it and see what happens
> 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)
