Jline is BSD licensed, so it should be compatible with EPL afaik. If not , I'm quite convinced it might be possible to ask for a license change if needed. However, if the problem comes from IP, things might be different...
On Thu, Sep 16, 2010 at 08:54, Kirchev, Lazar <[email protected]> wrote: > If you plan to include command-line editing in gogo, if you are interested we > may > contribute what we have written so far in this direction. > > Regarding the jline library - we cannot use it in Equinox because of > licensing issues. > > Regards, > Lazar > > -----Original Message----- > From: Derek Baum [mailto:[email protected]] > Sent: Friday, September 10, 2010 6:22 PM > To: users > Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo > > On 10 September 2010 15:38, Kirchev, Lazar <[email protected]> wrote: > > I agree that command-line editing would be useful in gogo. > > I expect that gogo will provide or integrate with a command line editing > provider in the next few months. > > Until then you can see how Karaf have provided command-line editing using > jline. > > > > Regards, > > Derek > > > > > >> >> Lazar >> >> -----Original Message----- >> From: Derek Baum [mailto:[email protected]] >> Sent: Friday, September 10, 2010 4:51 PM >> To: users >> Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo >> >> My solution does not involve modifying telnet or ssh provider code. Instead >> a new gogo shell command is provided to replace the input stream of a >> session with a wrapped editing stream _after_ createSession() is called. >> >> Derek >> >> On 10 September 2010 07:14, Kirchev, Lazar <[email protected]> wrote: >> >> > Actually currently I implemented this in a way similar to the one >> suggested >> > by you - >> > I implement my own telnet command, and wrap the telnet streams before >> > passing them to >> > createSession(). In my particular case it is a solution, but made me >> think >> > about the more general >> > case of a provider, which does not implement editing. For example, the >> > simple telnet server, >> > built in GoGo. It is not possible to add editing capabilities >> > transparently, without >> > modifying the code. >> > >> > Regards, >> > Lazar >> > >> > -----Original Message----- >> > From: Derek Baum [mailto:[email protected]] >> > Sent: Friday, September 10, 2010 7:55 AM >> > To: users >> > Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo >> > >> > On 9 September 2010 14:28, Richard S. Hall <[email protected]> wrote: >> > >> > > On 9/9/10 4:41, Kirchev, Lazar wrote: >> > > >> > >> Regarding the shell, I have another question. Currently we are working >> > on >> > >> adopting GoGo as the shell in Equinox. I am writing some features over >> > GoGo >> > >> to provide command line editing supportability, e.g., for telnet >> input. >> > I >> > >> implement separately the handling of the telnet protocol and the >> editing >> > of >> > >> the input (which includes processing of backspace, dell, arrows, >> > history, >> > >> etc.). The editing processor wraps the telnet streams and passes the >> > wrapped >> > >> streams to the createSession() method. In this way, the telnet handler >> > >> provider should be aware of the editing processor and use it before >> > creating >> > >> a session. But in general, this may not be the case. A provider may >> > provide, >> > >> for example, a bundle with ssh support, a web console, etc. If the >> > provider >> > >> has no notion of the existence of the editor, he/she will not use this >> > >> functionality. So is it possible such wrapping to be done by the >> > >> CommandProcessor, when creating the CommandSession? If GoGo provides >> an >> > >> interface for stream wrapping, the CommandProcessor may check when >> > creating >> > >> the session if there is a registered service, implementing this >> > interface, >> > >> and if there is such a service, it may wrap the streams so that the >> > editing >> > >> functionality becomes available transparently for the provider. >> > >> >> > > >> > > This sounds like a feature request and seems reasonable. Not sure if >> this >> > > is something that should be discussed as a Gogo-specific feature or a >> > > potential standard feature. Perhaps Derek has a comment. >> > >> > >> > It may not always be desirable for the CommandProcessor to wrap streams >> as >> > you suggest. >> > >> > Consider a telnet or ssh bundle that is unaware of your editing processor >> > and that implements its own editing. It would not want to be >> automatically >> > wrapped with some other editing support. >> > >> > It is however possible to wrap streams to achieve the decoupling that you >> > want using the current version of gogo. >> > >> > You could provide a gogo command to enable command-line editing in the >> > current session. This command would just need to call >> > CommandSession.setInput(editingStream), to replace the original >> InputStream >> > used in CommandProcessor.createSession(). (The gogo shell could also be >> > changed to that it automatically enabled command-line editing, according >> to >> > the users preference). >> > >> > The only problem is that CommandSession does not have a setInput() >> method! >> > Item #5 in this bug request suggested adding such a method: >> > https://www.osgi.org/bugzilla/show_bug.cgi?id=49 >> > >> > 5. InputStream setInput(InputStream in); >> > >> > When adding a ReadLine history/completion facility to an existing >> session, >> > it >> > is necessary to change the session input source. Current this can only be >> > done >> > at session creation. >> > >> > But Peter deemed it unnecessary: >> > >> > > 8. #49.5 Add InputStream setInput(InputStream in) for history >> etc. >> > I >> > disagree. The request behavior can easily be gotten by proxying the input >> > stream, I think. Lets try to keep it simple. >> > >> > This means that a known InputStreamProxy must be passed to >> > CommandProcessor.createSession() so that setInput() can be achieved by >> > casting CommandSession.getKeyboard() to InputStreamProxy and calling the >> > appropriate method. >> > >> > I was OK with this, but in your case it breaks the decoupling you wanted >> as >> > the Telnet processor must know to use an InputStreamProxy. >> > >> > >> > Regards, >> > >> > >> > Derek >> > >> > >> > >> > >> > > >> > > >> > > And I have a question regarding getting commands help. Currently we >> use >> > an >> > >> adaptor for the equinox commands, so that they become visible in GoGo. >> > The >> > >> adapter registers the osgi.command.function property with a list >> > containing >> > >> all names of the available equinox commands. Actually it does not >> > provide >> > >> methods for each of them, but in a main() method decides which one >> > should be >> > >> called (the adaptor cannot have hardcoded methods for all commands, >> > because >> > >> it is not known in advance what commands the user bundles will >> > register). >> > >> The problem is that GoGo help command does not list the method names, >> > >> provided by the adaptor in the osgi.command.function (because it >> checks >> > for >> > >> each of them if it is provided as a public method of the adaptor >> class). >> > Is >> > >> this a bug, or intended behavior? According to the RFC, the command >> > provider >> > >> should have public methods for the provided commands. I guess this is >> > the >> > >> reason for the behavior of GoGo help command, but in the particular >> case >> > of >> > >> the this is not feasible. >> > >> >> > > >> > > Yeah, the method-per-command approach is the recommended approach and >> the >> > > annotations were made to support that approach. We'll have to >> investigate >> > if >> > > there is something we can do here as a Gogo-specific workaround, but >> the >> > > whole main() approach is purely a legacy crutch to help people migrate >> > old >> > > commands to Gogo, so it is not something we intend to encourage people >> to >> > > use. In the long run, Equinox commands should be ported. >> > > >> > > In the short term, we can try to find a way to display more >> > info...remember >> > > "help" is just a command, so we can always have an alternate >> > implementation. >> > > >> > > -> richard >> > > >> > > >> > > Regards, >> > >> Lazar >> > >> >> > >> -----Original Message----- >> > >> From: Richard S. Hall [mailto:[email protected]] >> > >> Sent: Wednesday, September 08, 2010 4:20 PM >> > >> To: [email protected] >> > >> Subject: Re: Implementation of the last APIs, added to RFC 147, in >> GoGo >> > >> >> > >> On 9/8/10 5:47, Kirchev, Lazar wrote: >> > >> >> > >>> Hello, >> > >>> >> > >>> I would like to ask when the last additions to RFC 147 may be >> expected >> > in >> > >>> the GoGo implementation? I am particularly interested in the Scope >> and >> > >>> Terminal APIs. I am writing some shell code which can make use of >> these >> > >>> features. I checked the jira, but couldn't find any issues related >> with >> > >>> this. >> > >>> >> > >> We need to have some discussion about how to deal such provisional >> OSGi >> > >> APIs, once we do that, we just need to find the time to do it. >> > >> >> > >> -> richard >> > >> >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: [email protected] >> > >> For additional commands, e-mail: [email protected] >> > >> >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: [email protected] >> > >> For additional commands, e-mail: [email protected] >> > >> >> > >> >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [email protected] >> > > For additional commands, e-mail: [email protected] >> > > >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
