[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750703#comment-16750703
]
Guillaume Nodet edited comment on FELIX-6034 at 1/24/19 4:22 AM:
-----------------------------------------------------------------
The service requirements are not really used at runtime per se, it's used while
the deployment agent computes the list of required bundles using the osgi
resolver / resources / etc...
>From a versioning pov, the felix bundles should not add new requirements in
>micro releases, even is that's not caught by any semantic versioning check. I
>suggest to revert the change, release a compatible version and add the change
>in new version with at least a minor version increase.
>From a gogo pov, I'm not sure why this requirement has been added. The gogo
>bundles can work independantly, the proof being that Karaf does not use them
>all. Commands are discovered by gogo, so there are not strong requirements to
>be added here. If there is a requirement to be added, it should be a
>requirement on services with a 0..N cardinality, not a mandatory requirement
>on a capability that only the gogo command provides. This really sounds like
>some magic requirements in order to tie bundles together in a usable piece.
>This goes against the reusability of the osgi manifest imho.
>From a karaf pov, once a minor release of those bundles is out, it should be
>able to tweak the feature descriptors to provide the required capability from
>one of the bundle if needed.
was (Author: gnt):
The service requirements are not really used at runtime per se, it's used while
the deployment agent computes the list of required bundles using the osgi
resolver / resources / etc...
>From a versioning pov, the felix bundles should not add new requirements in
>micro releases, even is that's not caught by any semantic versioning check. I
>suggest to revert the change, release a compatible version and add the change
>in new version with at least a minor version increase.
>From a gogo pov, I'm not sure why this requirement has been added. The gogo
>bundles can work independantly, the proof being that Karaf does not use them
>all. Commands are discovered by gogo, so there are not strong requirements to
>be added here. If there is a requirement to be added, it should be a
>requirement on services with a 0..N cardinality, not a mandatory requirement
>on a capability that only the gogo command provides. This really sounds like
>some magic requirements in order to tie bundles together in a usable piece.
>This goes against the reusability of the osgi manifest imho.
> Gogo JLine requirement doesn't allow to embed gogo.jline
> --------------------------------------------------------
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
> Affects Versions: gogo.jline-1.1.2
> Reporter: Jean-Baptiste Onofré
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
