You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Guillaume Nodet (JIRA)" <ji...@apache.org> on 2019/01/24 04:23:00 UTC
[jira] [Comment Edited] (FELIX-6034) Gogo JLine requirement doesn't
allow to embed gogo.jline
[ 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)