[
https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767071#comment-16767071
]
Peter Kriens commented on FELIX-6056:
-------------------------------------
By wrapping it in a single bundle you force others to follow
{color:#333333}your{color} Promises' {color:#FF0000}implementation{color} and
that version is not always compatible. in a runtime (The version we currently
use for R7 is R6 promises.) Since SCR is such a fundamental bundle it should
not force such constraints on other people's runtime.
Notice that this is mostly caused because it includes API
{color:#FF0000}and{color} an implementation. An API only would still be not
cohesive but would work ok. Since others do this as well, there is no backward
compatibility on the API possible. You therefore must import it [1,1.1) This
constrained will then likely cause multiple class spaces in more complex
runtimes and that is almost always havoc. That is why importing [1,2) for a
provided package is basically throwing a big wrench in the semantic versioning.
Exporting a package that is not part of your primary responsibility is
fundamentally wrong in component based design. Yes, I feel we messed up on the
SCR Runtime API to force Promises in the ScrComponentRuntime methods and it is
inconvenient to require 3 instead of 1 bundle but the cause is the bad API
design that references another spec, this causes an _external_ reference.
Solving this problem by exporting those references is a hack and will cause
problems.
At my customers I see the problems always around the bundles that start doing
these hacks, never around simple clean honest manifests that refer to what they
should refer to. Apache Felix has always been extremely good in this respect so
I was quite surprised when I learned about this.
> 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)
