GoGo Command requires a runtime

[Alexander Broekhuis <a....@gmail.com>]

Hi all,

Since a few releases GoGo uses a cap/req model to get a complete set of
bundles (shell, runtime, command). While this makes sense in most cases,
this introduces a new problem for us. When creating a component that
implements some commands, it is now always coupled to the shell bundle as
well. This adds (IMO) unneeded dependencies, which could have been
optional. Eg when testing that component I now have to include the shell,
which in turn requires the commands as well. This also requires me to
update runconfigurations to use the nointeractive flag for a headless
environment.

Perhaps I'm overlooking something, but is there a clean way to solve this
with the current gogo version? In previous versions I could just add the
runtime and everything would resolve as expected.

Thanks!

-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: GoGo Command requires a runtime

[Raymond Augé <ra...@liferay.com.INVALID>]

Another option which is less ideal but useful if you have a strong reason
not to make the gogo annotations import optional (maybe there are too many
bundles to change or something)

then you can tell bnd that certain capabilities (particularly ones which
are `effective:=active`) are already provided during assembly resolution by
adding the instruction in your bndrun files:

```
-runsystemcapabilities:
org.apache.felix.gogo;org.apache.felix.gogo="shell.implementation";version:Version="1.0.0";
implementation.name="gogo.shell"
```

On Thu, Nov 4, 2021 at 9:17 AM Raymond Augé <ra...@liferay.com>
wrote:

> So this is because of the imported package `org.apache.felix.gogo.command`
> for the annotations right?
>
> Just make that import optional!
>
> On Thu, Nov 4, 2021 at 6:20 AM Alexander Broekhuis <a....@gmail.com>
> wrote:
>
>> Hi all,
>>
>> Since a few releases GoGo uses a cap/req model to get a complete set of
>> bundles (shell, runtime, command). While this makes sense in most cases,
>> this introduces a new problem for us. When creating a component that
>> implements some commands, it is now always coupled to the shell bundle as
>> well. This adds (IMO) unneeded dependencies, which could have been
>> optional. Eg when testing that component I now have to include the shell,
>> which in turn requires the commands as well. This also requires me to
>> update runconfigurations to use the nointeractive flag for a headless
>> environment.
>>
>> Perhaps I'm overlooking something, but is there a clean way to solve this
>> with the current gogo version? In previous versions I could just add the
>> runtime and everything would resolve as expected.
>>
>> Thanks!
>>
>> --
>> Met vriendelijke groet,
>>
>> Alexander Broekhuis
>>
>
>
> --
> *Raymond Augé* (@rotty3000)
> Senior Software Architect *Liferay, Inc.* (@Liferay)
> OSGi Fellow, Java Champion
>


-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion

Re: GoGo Command requires a runtime

[Raymond Augé <ra...@liferay.com.INVALID>]

So this is because of the imported package `org.apache.felix.gogo.command`
for the annotations right?

Just make that import optional!

On Thu, Nov 4, 2021 at 6:20 AM Alexander Broekhuis <a....@gmail.com>
wrote:

> Hi all,
>
> Since a few releases GoGo uses a cap/req model to get a complete set of
> bundles (shell, runtime, command). While this makes sense in most cases,
> this introduces a new problem for us. When creating a component that
> implements some commands, it is now always coupled to the shell bundle as
> well. This adds (IMO) unneeded dependencies, which could have been
> optional. Eg when testing that component I now have to include the shell,
> which in turn requires the commands as well. This also requires me to
> update runconfigurations to use the nointeractive flag for a headless
> environment.
>
> Perhaps I'm overlooking something, but is there a clean way to solve this
> with the current gogo version? In previous versions I could just add the
> runtime and everything would resolve as expected.
>
> Thanks!
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>


-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion