glimmerveen commented on pull request #16:
URL: https://github.com/apache/felix-dev/pull/16#issuecomment-642212232


   > Good point, it has been removed by 
[7b3dd32#diff-2befb2bc3b1c6eb0738ac341e9ad1ef0](https://github.com/apache/felix-dev/commit/7b3dd3202ee32198cc7582979c2f5c3648bf0ec4#diff-2befb2bc3b1c6eb0738ac341e9ad1ef0)
   > @jbonofre ?
   > 
   > Ah, I see it was removed because Karaf uses its own method to create the 
shell. I guess we could use a different way to not start the shell from the 
activator, maybe a system property to disable the shell that could be set by 
karaf ? @glimmerveen do you think you could add a system property to disable 
the activator code if needed ?
   
   I guess adding a framework property check to see if the shell should be 
activated or not can be added, but I am not sure how it is going to solve the 
issue. In Karaf's use of gogo.jline, org.apache.karaf.shell.core bundle will 
hold two Bundle-Activator implementations: one from gogo.jline and one from 
[Karaf's 
shell](https://github.com/apache/karaf/blob/master/shell/core/src/main/java/org/apache/karaf/shell/impl/console/osgi/Activator.java).
 As only one activator may be declared as 'the' bundle activator, 
org.apache.karaf.shell.core configures [it's 
own](https://github.com/apache/karaf/blob/310ff72fa857fcbdcd9f217628138bc774bcd1fe/shell/core/pom.xml#L183).
   
   Before gogo.jline used the Header annotation to declare the 
Bundle-Activator. This would conflict in the generation of the 
org.apache.karaf.shell.core bundle as bnd would find two different bundle 
activators being configured. Unfortunately this was solved in a way that broke 
gogo.jline as a stand-alone bundle.
   
   The change in this PR reintroduces the Bundle-Activator for gogo.jline, 
while still allowing Karaf the inline it in its own shell bundle, without 
re-introducing the issue at Karaf of having two bundle activators configured.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to