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é <raymond.a...@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.broekh...@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
