[
https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767055#comment-16767055
]
Carsten Ziegeler edited comment on FELIX-6056 at 2/13/19 11:39 AM:
-------------------------------------------------------------------
I'm not sure what exactly we're trying to fix here. So far you need a single
bundle for SCR. By not including promise/functions you out of a sudden need
three bundles.
I understand the theoretical discussions about this, but in practice both
bundles are released once every couple of years - next release will be with R8
I guess.
So why can't we just inlcude the latest version, properly export/import it and
are done with it for the next N years?
was (Author: cziegeler):
I'm not sure what exactly we're trying to fix here. So far you should need a
single bundle for SCR. By not including promise/functions you out of a sudden
need three bundles.
I understand the theoretical discussions about this, but in practice both
bundles are released once every couple of years - next release will be with R8
I guess.
So why can't we just inlcude the latest version, properly export/import it and
are done with it for the next N years?
> 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)
