-
Notifications
You must be signed in to change notification settings - Fork 28
osgi.enroute.gogo.shell.provider errors on Windows #73
Comments
There seems to be an additional issue with enroute shell on Windows when running from eclipse. (running with cmd.exe seems to work fine). The console prints out the motd and the prompt "G!" but does not accept any input. The problem seems to be in jline (jline/jline2#245). I have posted some additional info about jline internals in the referenced issue above so the only way to fix enroute shell on windows in eclipse is using the "-Djline.terminal=jline.UnsupportedTerminal" JVM argument. Maybe we can add a fix by detecting such an environment (windows && eclipse) and programmatically set the system property for jline. |
You might want to try the new Gogo shell from Felix. Since Neil added JLine to enRoute Gogo they also added Jline.
Kind regards,
Peter Kriens
… On 29 Nov 2016, at 16:58, S.W. ***@***.***> wrote:
There seems to be a additional issue with jline on Windows in a couple of cases (jline/jline2#245 <jline/jline2#245>). The enroute shell does not work when runnimg from eclipse (running from cmd.exe seems to work). The console prints out the motd an the prompt "G!" but does not accept any input. I have posted some additional info about jline internals in the referenced issue above so the only way to fix enroute shell on windows in eclipse is using the "-Djline.terminal=jline.UnsupportedTerminal" JVM argument. Maybe we can add a fix by detecting such an environment (windows && eclipse) and programmatically set the system property for jline.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#73 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMPLnvhRLFShlJtzLqFgUncopZolYLhks5rDEutgaJpZM4K_Dc6>.
|
Using the "org.apache.felix:org.apache.felix.gogo.jline:1.0.0" bundle on Windows 10:
Running in cmd.exe works with autocomplete and all that stuff but executing a command results in a empty line printed out without any result for most of the commands. e.g. scr:list gives me the expected result but context:bundles, system:nanotime, ... just prints out a empty line without a result. Running in powershell is kind of similar but instead of an empty line I just get the prompt again without any output. Using the "org.apache.felix:org.apache.felix.gogo.shell:1.0.0" bundle works as expected running in eclipse, cmd and powershell (but without all the neat stuff jline brings e.g. autocomplete, coloring etc...) So currently the gogo:shell seems to be the only one which works correctly on Windows and therefore seems to be the best bet on Windows unfortunately. |
Include jansi native libaries in osgi.enroute.gogo.shell.provider bundle
Hi, |
I think this is all fixed now. Just start over from a completely clean workspace.
Kind regards,
Peter Kriens
… On 4 Feb 2017, at 22:46, Oliver ***@***.***> wrote:
Hi,
I'm afrait, I cannot continue with the tutorial because of this. Sorry, I do not know how to try the new Gogo shell from Felix. I tried to modify the -runbundles but that doesn't do the trick...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#73 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMPLtDe6kO5v0lZIaOeOm3NMwL56Qp3ks5rZPG1gaJpZM4K_Dc6>.
|
I'm afraid it still is an issue on Windows... I started over from a fresh workspace and had also the local Maven repository completely deleted. I'm using version 2.0.0 of the My
So far, this all seems completely aligned with the Maven tutorial. Still, it won't run on Windows. Ubuntu is fine, though! 🥇 I'm thinking about some kind of Continuous Integration that can automatically test this for Windows, too. Is there something like this already set up or would that be of interest for the enRoute project? Kind regards |
Can you provide a PR? |
I have observed on Windows 7 and Windows 10 that using osgi.enroute.gogo.shell.provider gives Exception in thread "OSGi enRoute Gogo Shell" java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no jansi in java.library.path]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at jline.AnsiWindowsTerminal.detectAnsiSupport(AnsiWindowsTerminal.java:57)
at jline.AnsiWindowsTerminal.(AnsiWindowsTerminal.java:27)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
at jline.TerminalFactory.create(TerminalFactory.java:102)
at jline.TerminalFactory.get(TerminalFactory.java:186)
at jline.TerminalFactory.get(TerminalFactory.java:192)
at osgi.enroute.gogo.shell.provider.Shell$1.run(Shell.java:153)
at java.lang.Thread.run(Unknown Source)
Also referenced here: osgi/osgi.enroute#17
This should actually be the correct place for this issue.
The text was updated successfully, but these errors were encountered: