Community
Participate
Working Groups
Build Identifier: 3.7 This bug is for adapting the Equinox commands for use in the GoGo shell, or vice versa - using the GoGo functionality through the Equinox shell. Reproducible: Always
An adapter bundle for adapting the Equinox commands for use in the GoGo shell is ready. I also added the telnet and command line editing features (backspace, arrows, del, history, etc) to the adapter bundle. I haven't implemented tab completion, because the latest additions to the RFC 147, regarding command completion (the Scope interface) are not implemented in GoGo yet. I would like to ask about the details of submitting the adapter in the CVS for the incubator. It is a new project, the code will be stored in the repository, but who is responsible for the built? Also, since this adapter is intended to work over GoGo, how should this dependency be indicated? Include the gogo bundles in the project? And what about tests? There is a test suite for the equinox project, but is there some placeholder for tests in the incubator, or each project is responsible for its own tests? Finally, the patent issues - Tom wrote part of the current implementation of the adapter, so how should the lisencing headers look like?
Created attachment 185203 [details] Adapter for Equinox commands for Gogo and telnet supportability The archive contains: - a project, which provides an adapter for Equinox commands to be called from the Gogo shell, as well as support for Equinox ConsoleSession and supportability features for telnet - terminal type negotiation, command line editing (backspace, del, arrows, home, end, etc). The project have dependency on org.apache.felix.gogo.runtime - the bundle, built from this project - the Gogo shell bundles - sample config.ini with which to run the adapter bundle and the Gogo shell with Equinox Equinox should be started without -console option. Currently this is the only way not to have the built-in console disabled so that an external console (Gogo in this case) could be run. I am going to open a CQ to get approval to submit the project in the Equinox incubator.
(In reply to comment #2) > Created an attachment (id=185203) [details] > Adapter for Equinox commands for Gogo and telnet supportability > > The archive contains: > > - a project, which provides an adapter for Equinox commands to be called from > the Gogo shell, as well as support for Equinox ConsoleSession and > supportability features for telnet - terminal type negotiation, command line > editing (backspace, del, arrows, home, end, etc). The project have dependency > on org.apache.felix.gogo.runtime > > - the bundle, built from this project > - the Gogo shell bundles > - sample config.ini with which to run the adapter bundle and the Gogo shell > with Equinox > > Equinox should be started without -console option. Currently this is the only > way not to have the built-in console disabled so that an external console (Gogo > in this case) could be run. > > I am going to open a CQ to get approval to submit the project in the Equinox > incubator. Where in the incubator is most suitable to add this project? Currently there is one project for the built-in console, separated from the framework, in incubator/archive. Is it OK to place it there, or probably create in incubator/console?
(In reply to comment #3) > > Where in the incubator is most suitable to add this project? Currently there is > one project for the built-in console, separated from the framework, in > incubator/archive. Is it OK to place it there, or probably create in > incubator/console? I recommend we create a new incubator/console directory. I also recommend we move the built-in console separation project to the incubator/console directory. The archive is really for stuff that we put on the shelf but did not want to completely delete from CVS. I would prefer this all to be co-located. When we move to graduating this stuff I imagine it would go under the "components" sub directory under org.eclipse.equinox. Another option is that we would create a new sub directory just for console when we graduate, but I am not sure that is necessary.
(In reply to comment #4) > (In reply to comment #3) > > > > Where in the incubator is most suitable to add this project? Currently there is > > one project for the built-in console, separated from the framework, in > > incubator/archive. Is it OK to place it there, or probably create in > > incubator/console? > > I recommend we create a new incubator/console directory. I also recommend we > move the built-in console separation project to the incubator/console > directory. The archive is really for stuff that we put on the shelf but did > not want to completely delete from CVS. I would prefer this all to be > co-located. When we move to graduating this stuff I imagine it would go under > the "components" sub directory under org.eclipse.equinox. Another option is > that we would create a new sub directory just for console when we graduate, but > I am not sure that is necessary. I submitted the project to incubator/console and moved the old separated console project from incubator/archive to incubator/console. Now I am waiting to get rights for tools.orbit to put there the Gogo jars. After that the project could be added to the incubator build. For this to happen I should contact the webmaster of the build server, I guess? Or I have rights to do it myself?
How can I request the console supportability bundle to be included in the incubator build? I can open a bug a Hudson job for it to be created, but I think that it should not have a separate job. So probably open a bug to include it in the job, which builds the incubator? But when browsing the Hudson, I could not find job for the incubator. Do I miss something?
(In reply to comment #6) > How can I request the console supportability bundle to be included in the > incubator build? I can open a bug a Hudson job for it to be created, but I > think that it should not have a separate job. So probably open a bug to include > it in the job, which builds the incubator? But when browsing the Hudson, I > could not find job for the incubator. Do I miss something? We will have to open a new bug against Eclipse->Platform->Releng. We first need a gogo bundle included in the orbit build that we can reference and use in the equinox incubator build. Once that is available I can open a bug against releng to get Kim to start building the new bundles.
> > We will have to open a new bug against Eclipse->Platform->Releng. We first > need a gogo bundle included in the orbit build that we can reference and use in > the equinox incubator build. Once that is available I can open a bug against > releng to get Kim to start building the new bundles. I forgot to mention that I added the gogo bundle in the orbit repository. It remains only to define two properties, so that it is correctly handled by the build.
I finally added to gogo runtime bundle to the orbit build and opened bug 334739 to include it in the incubator build.
(In reply to comment #9) > I finally added to gogo runtime bundle to the orbit build and opened bug 334739 > to include it in the incubator build. I mean to include the console supportability bundle to the equinox incubator build.
Lazar, are there any instructions for running Equinox with the GoGo shell? It seems that more bundles are necessary which aren't in Orbit yet. Here is what I have so far: - added 'osgi.console.enable.builtin=false' to config.ini - added bundle 'org.apache.felix.gogo.runtime' and set it to autostart - added bundle 'org.eclipse.equinox.console.supportabilty' and set it to autostart Here is the debug output I get: Configuration location: file:... Configuration file: file:... Install location: file:... Framework located: file:... Framework classpath: file:... Debug options: file:... loaded Time to load bundles: 8 osgi> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: gosh at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:455) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:384) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:79) at org.eclipse.equinox.console.command.adapter.Activator$SessionCustomizer$1.run(Activator.java:114) at java.lang.Thread.run(Thread.java:662) <prompt is gone, i.e. not available anymore>
(In reply to comment #11) > Lazar, are there any instructions for running Equinox with the GoGo shell? It > seems that more bundles are necessary which aren't in Orbit yet. > > Here is what I have so far: > - added 'osgi.console.enable.builtin=false' to config.ini > - added bundle 'org.apache.felix.gogo.runtime' and set it to autostart > - added bundle 'org.eclipse.equinox.console.supportabilty' and set it to > autostart > Yes, there are two other bundles in addition to the gogo runtime bundle to run Equinox with Gogo. I added to orbit only the one necessary for building the org.eclipse.equinox.console.supportabilty bundle. You need also the following bundles: org.apache.felix.gogo.command org.apache.felix.gogo.shell Probably you will need to add osgi.framework.activeThreadType=normal to the config.ini so that the framework does not exit when the buiilt-in console is not active. Currently, when osgi.console.enable.builtin is set to false, the FrameworkCommandProvider is not registered, so most of the framework commands are not available. Recently I migrated the command provider to gogo style commands and they do not depend any more on the builtin console, but I haven't committed this yet. If you want to have the framework commands with Gogo, you should not set the osgi.console.enable.builtin property at all. And do not add the -console option when you start the framework. In this way the builtin console will register the commands and then will exit, and you will have Gogo with the Equinox commands.
Created attachment 193149 [details] Felix gogo command bundle
Created attachment 193150 [details] Felix gogo shell bundle
I attached the other two gogo bundles to this bug.
I am moving this to components since that is where the new bundle will graduate to. I also added it to the planning wiki at http://wiki.eclipse.org/Equinox/Plan/Juno/components#Console Lazar I placed your name next to this plan item for Juno. You may also want to open another umbrella bug which covers and tracks other enhancements you have planned for the console. Simply make that plan bug depend on other bugs you have open that you plan to contribute to.
Comments on the incubator console: 1) org.eclipse.equinox.console.supportability - needs a better name. Not sure why we don't just use org.eclipse.equinox.console. 2) I don't understand the man command. Seems to just turn around and call equinox:help command. Why is the man command needed? 3) Not sure I get the equinox:help command. - It has some -legacy and -all option. I think the default behavior should be the current -all behavior. - It eventually will execute the unscoped help command. Depending on the order the gogo shell looks up commands in scopes it is possible that this will just recurse back into the equinox:help command. I believe we need to scope the execution of the help to call felix:help so we don't recurse. - May want to consider calling felix:help and if it is not found then trying gogo:type command. - for legacy help we should not be listing the _help methods as help commands. 4) I would like to get by without the org.apache.felix.gogo.command bundle. The equinox:help command seems to have a dependency on the felix:help command. I think we should petition the felix gogo team to move the felix:help command to the gogo:help scope and have it provided by the org.apache.felix.gogo.runtime bundle. The org.apache.felix.gogo.runtime bundle defines the annotations that are expressly used by the help command so it makes sense that the org.apache.felix.gogo.runtime bundle would provide the help command. 5) Is there a reason the legacy commands provided by org.eclipse.core.runtime.internal.adaptor.EclipseCommandProvider are not implemented in the org.eclipse.equinox.console.commands.EquinoxCommandProvider class? diag, disableBundle, enableBundle, disabledBundles? I think the framework should not register these legacy commands if osgi.console.enable.builtin=false and they should instead be provided by the org.eclipse.equinox.console.commands.EquinoxCommandProvider or some other command provider. 6) Is there a way to make the equinox scope be the default scope? 7) I don't understand what org.eclipse.equinox.console.command.adapter.Activator.ProcessorCustomizer.addingService(ServiceReference<CommandProcessor>) is doing. Seems that for every CommandProcessor registered you will start both the TelnetCommand and SshCommand objects which will register new command services. I am wondering why we would need multiple of these registered. Is there only ever one CommandProcessor service? 8) I would prefer to move the ssh and jaas support to be in a separate bundle. 9) I think the EclipseStarter should attempt to start the org.eclipse.equinox.console.supportability bundle if the osgi.console.enable.builtin=false. I also think the org.eclipse.equinox.console.supportability should attempt to start the required gogo bundles transiently. I have been working on these changes, but have not pushed them up yet. Overall I think the functionality is in a good state and we should move forward with graduating this to the bundles project. Lazar please look at my comments and lets see if we can agree on fixing some of them in the incubator in the mean time.
Forgot another comment 10) Need to remove dependencies on equinox internals: org.eclipse.osgi.framework.internal.core.AbstractBundle; - used to try and display the Protection domain from the "bundle" command. I just removed this code. org.eclipse.osgi.framework.internal.core.Util; - used for sorting based on string. I simply copied this class into the console bundle. org.eclipse.osgi.internal.profile.Profile; - I changed the code to use reflection for this. I have these changes locally and will push them up if you agree Lazar.
(In reply to comment #17) > 9) I think the EclipseStarter should attempt to start the > org.eclipse.equinox.console.supportability bundle if the > osgi.console.enable.builtin=false. I also think the > org.eclipse.equinox.console.supportability should attempt to start the required > gogo bundles transiently. I have been working on these changes, but have not > pushed them up yet. > I did this in bug 359709, but we will have to update the default bundle name if we change the name of org.eclipse.equinox.console.supportability.
(In reply to comment #17) > - May want to consider calling felix:help and if it is not found then trying > gogo:type command. > I changed the help command to call the scoped felix:help method. I did not fall back to calling gogo:type, but I still think that would be a good idea. http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/commit/?id=adaae623cd251d19edee037b0b751095cb4d229f I removed an unused method with: http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/commit/?id=69b8e65329062b8d0265ef104f7ec4c592558128 I removed use of equinox internals with: http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/commit/?id=83fe4a31818ffb39e51fd09ccc4dcd31b88701fb I added code to start the gogo felix bundles from the activator at: http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/commit/?id=ab8463e3c0066498fd179ab073d0a6367f80984f
First of all, sorry for the delayed reply - I was out of office for several days and I come back today. I will reply to each question according to its number from posts 17/18: 1) I agree about the name and I think that org.eclipse.equinox.console is OK. If you also agree, I will change the name, the package names and the tests accordingly. 2) The man command is just for usability. I think there are users of the built-in console who used to list the available commands with man instead of help. From the built-in console point of view it is one and the same - when an unknown command is passed on the command line, the console just lists all available commands. But those who are used to passing man now will be surprised that it does not work. That is why I created it as an alias for the help command. 3) about the help command: > - It has some -legacy and -all option. I think the default behavior should be >the current -all behavior. I agree - -all should be the default behavior. All these options are confusing for the users - I receive this feedback from some people who are using the console. Actually, I introduced them so that one could which type of commands to list - the legacy commands, or the default gogo/felix commands, or all of them. But since it turns out to be more confusing than helpful, it should be changed. I will fix this. I will track it in bug 359995. > - It eventually will execute the unscoped help command. Depending on the >order the gogo shell looks up commands in scopes it is possible that this will >just recurse back into the equinox:help command. I believe we need to scope >the execution of the help to call felix:help so we don't recurse. Yes, I overlooked this detail - currently felix/gogo scopes are with higher priority, but this could be changed. So it is best to scope it. > - May want to consider calling felix:help and if it is not found then trying >gogo:type command. Won't this be a little confusing for the user, since the output of gogo:type will not be what the user expects? Moreover, I am not sure if it will be helpful for the user to know how much commands are registered for each scope when we actually cannot list them. > - for legacy help we should not be listing the _help methods as help commands. I thought I have fixed this some time ago, but now I see that I did not push the local change. I will push it. I will track this issue in the current bug. 4) Yes, the most important command here is the help command. Almost for all other commands there are commands with similar functionality in equinox - only four file commands are not available, and the OBR commands, but we do not need them at all. So if we have the help command in the runtime, we could get rid of the gogo command bundle. 5) No, there is no reason - actually, I used the EquinoxCommandProvider as a "pilot" for the migration of the legacy commands to the new RFC 147 type commands. I planned to make the same for the EclipseCommandProvider and I will do it now. Tracking this in bug 359996. 6) yes, there is - by setting the SCOPE variable. 7)The registration of telnet/ssh should not be there, but in the start() method, where the other commands are registered. I will track this issue in the current bug. 8) the ssh/jaas support is not essential for the functioning of the shell, and I think it is decoupled from the other part of the console, so it could be moved to its own bundle with some minor changes. Tracking this in bug 359997. 9) and 10) - I agree.
Just to note a small detail regarding the equinox commands - init and launch commands are useless when the console is separated from the framework.
(In reply to comment #22) > Just to note a small detail regarding the equinox commands - init and launch > commands are useless when the console is separated from the framework. I suggest removing them if they are still there in the console bundle.
(In reply to comment #23) > (In reply to comment #22) > > Just to note a small detail regarding the equinox commands - init and launch > > commands are useless when the console is separated from the framework. > > I suggest removing them if they are still there in the console bundle. They are, but I will remove them. I will track this in the current bug.
1. If felix:help command could not be found, A message should be displayed that probably gogo commands bundle is not installed 2. The framework should register EclipseCommandProvider only if osgi.console.enable.builtin is set to true.
Fixed bug 359995. Fixed setting SCOPE to equinox with http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/commit/?id=5c784efdd39e5a31874d647bc59f8cc781af0b64 In the fix I set the property programmatically. However, there is in the gogo shell bundle a configuration file, which assigns value gogo:* to SCOPE, so the patch will work only if the configuration is missing. I will change the configuration file itself and update the orbit repository.
(In reply to comment #25) > 1. If felix:help command could not be found, A message should be displayed that > probably gogo commands bundle is not installed > > 2. The framework should register EclipseCommandProvider only if > osgi.console.enable.builtin is set to true. both fixed.
Refactored support for multiple CommandProcessors. Submitted with commit http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/commit/?id=6a14fd0fdf67e8513b5ca5036e87e7affc13893d The registration of the telnet and ssh commands remained in the command processor tracker, but is conditional - the commands are registered only once. The registration should be there, because both commands depend on registered command processors.
Next steps: 1. Copy the console project to rt.equinox.bundles under the new name 2. Migrate the EclipseCommandProvider commands to the new console 3. Remove init and launch commands from the new console 4. Update org.apache.felix.gogo.shell bundle in orbit 5. Extract ssh to its own bundle
Console bundles copied from rt.equinox.incubator to rt.equinox.bundles with commit http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=b76a1e93e813b4c95466d65218aca9bb28fb698e
I noticed the 'org.eclipse.equinox.slf4j.stub' fragment. Do you intend to ship this fragment with Equinox? Do we just want to remove the constraint from the Orbit bundle instead? The new SLF4J version doesn't break if no impl. is present.
(In reply to comment #31) > I noticed the 'org.eclipse.equinox.slf4j.stub' fragment. Do you intend to ship > this fragment with Equinox? Do we just want to remove the constraint from the > Orbit bundle instead? The new SLF4J version doesn't break if no impl. is > present. No, we are not shipping this with Equinox. Actually, it was in the incubator only for compilation. Actually, if the logback impl of slf4j was used, it was completely unnecessary (the one in orbit provided the generic capability). But since the new version doesn't break, we will use it.
Regarding the init and shutdown commands - I think that still we cold leave them, even though the console is separated. The shoutdown command will have the semantics of the exit command - will stop the framework. As for the init command - currently it uninstalls all installed bundles and clears the permissions in the PermissionAdmin and the ConditionalPermissionAdmin, but only if the framework is not in state ACTIVE. Could we make it do these things regardsless of the state of the framework?
EclipseCommandProvider commands migrated to org.eclipse.equinox.console bundle with commit http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=8c8c2d910fa5313f94f2b7f7d1c04598eb2b61a5
Configuration of gogo shell bundle in orbit fixed to have equinox as default scope.
(In reply to comment #31) > I noticed the 'org.eclipse.equinox.slf4j.stub' fragment. Do you intend to ship > this fragment with Equinox? Do we just want to remove the constraint from the > Orbit bundle instead? The new SLF4J version doesn't break if no impl. is > present. Gunner, here the problem was with the Eclispe-GenericRequire constraint, which is required by the slf4j-api bundle in Orbit. The stub is actually a fix for this, and is only for compilation. Do you mean that the new slf4j version can do without this?
(In reply to comment #36) > Do you mean that the new slf4j version can > do without this? Yes, the new version can do without such a require, i.e. it will only log a message once if no fragment is present and then don't log anything at all. Thus, we can modify the bundle in Orbit to remove it.
(In reply to comment #37) > (In reply to comment #36) > > Do you mean that the new slf4j version can > > do without this? > > Yes, the new version can do without such a require, i.e. it will only log a > message once if no fragment is present and then don't log anything at all. > > Thus, we can modify the bundle in Orbit to remove it. The latest version of slf4j-api is 1.6.3, while the last in Orbit is 1.6.1. Then we should raise a CQ for using 1.6.3 and add it to Orbit? Or you meant to modify 1.6.1?
Fixed with commit http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=61b96b6e8095d80eab1707f38d6f4be9ec8d5023 Ssh/jaas support is moved to bundle org.eclipse.equinox.console.ssh. The tests for ssh/jaas are moved from org.eclipse.equinox.console.tests to org.eclipse.equinox.console.ssh.tests
Closing as fixed.
