I thought I'd add my $0.02 as a customer. I don't really care what console I get as long as it "doesn't suck" meaning that it's intuitive to use. I don't really care if I have to include another bundle or not to get the console - it's just another bundle in the sea of bundles that I already deploy. I DO care that I can turn the console on and off with -console.
On Dec 3, 2010, at 9:03 AM, Jeff McAffer wrote: > Lazar makes a good point that people are used to -console giving them "a > console". Some thoughts > > 1) Will there be people care what console -console gives them? > > 2) Put another way, can we make the assumption that if Gogo is around no one > is interested in using the built-in console? > > 3) if -console is still the trigger to make a console appear then "-console > none" cannot be used to turn off the old console and turn on gogo. Would be > odd for users. > > 4) if there is another means of turning off the built-in console then we need > some means of saying "when gogo is installed, turn off the other console". > If we assume yes to #2 then, for example, some disable.builtin.console > property could be set in p2 metadata related to Gogo. This is sort of like > how p2 cohabitates with update.configurator. We set a property to turn off > update.configurator's real work. > > 5) Assuming gogo currently does not look for any command line args (like > -console) there should be another bundle that looks for -console (whatever) > and triggers gogo. > > Jeff > > > On 2010-12-03, at 9:50 AM, Kirchev, Lazar wrote: > >> I think we already have such an option – specifying “-console none” disables >> both the discovery of CommandProvider services and ConsoleSession services. >> The disadvantage is that if “-console none” is used the >> FrameworkCommandProvider service is not registered. Probably an option >> whether to register this service or not should be added. >> >> Lazar >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Thomas Watson >> Sent: Friday, December 03, 2010 4:07 PM >> To: Equinox development mailing list >> Subject: Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo >> >> There are two things to consider. >> >> 1) The equinox console implementation currently discovers the equinox >> CommandProvider services which provide the set of commands to the equinox >> osgi> console. In a prototype that Lazar has been working on there is a >> bridge bundle that is able to map equinox CommandProvider services onto gogo >> commands. It may be necessary to disable the discovery of the >> CommandProvider services in the built-in framework console when using the >> gogo shell and equinox bridge bundle on top. >> >> 2) Currently the built-in console supports ConsoleSessions being created >> even if you don't specify the -console option. This allows a ConsoleSession >> service to be registered which provides the import/output for the equinox >> console. This is how the eclipse console view is able to establish a console >> session with the running host framework, even when -console is not used. The >> bridge bundle Lazar has worked on also is able to discover Equinox >> ConsoleSessions to provide a connection to the gogo shell. It may also be >> necessary to disable the discovery of the ConsoleSession services in the >> built-in framework console when using the gogo shell and equinox bridge >> bundle on top. >> >> What I am suggesting for 3.7 (Indigo) is to have a configuration option that >> completely disables these two things in the built-in framework console. It >> basically makes the built-in framework console deadcode so that we don't >> have to worry about it interfering with a console/shell bundle on top. >> >> Tom >> >> >> >> <image001.gif>"Kirchev, Lazar" ---12/03/2010 03:58:32 AM---Technically if >> the framework is configured with the Gogo bundles to be installed and >> started, and is run without the –console >> >> <image003.png> >> From: >> <image004.png> >> "Kirchev, Lazar" <[email protected]> >> <image003.png> >> To: >> <image004.png> >> Equinox development mailing list <[email protected]> >> <image003.png> >> Date: >> <image004.png> >> 12/03/2010 03:58 AM >> <image003.png> >> Subject: >> <image004.png> >> Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo >> >> >> >> Technically if the framework is configured with the Gogo bundles to be >> installed and started, and is run without the –console option, it should >> work just fine. But users are accustomed to use the -console option. When >> they eventually start Equinox, configured with Gogo, with the –console >> option, they will have a framework with two shells, fighting with each other >> for resources. This may be a problem. >> >> Lazar >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Jeff McAffer >> Sent: Friday, December 03, 2010 3:00 AM >> To: Equinox development mailing list >> Subject: Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo >> >> IMHO the bar for Indigo is pretty low. We need to make sure that Gogo can >> run properly on Equinox. All servicability extension work can be focused on >> using Gogo. Having a way to disable the current console would be interesting >> but not essential. Don't want the console? don't put -console on the command >> line. >> >> I'm reluctant to put any logic in the framework or launcher to choose >> between consoles or search for console implementations or... People shipping >> configurations where they want to use Gogo should setup their config to have >> Gogo installed and started. We may choose in the future to supply such a >> setup from Equinox and there can even be a bundle that looks for a -gogo >> command line arg but that should not be in the framework impl. >> >> So, what do we actually have to do here? >> >> Jeff >> >> >> On 2010-12-02, at 1:44 PM, Thomas Watson wrote: >> >> This is the kind of thing I want to address for 3.7 to enable the use of >> bundles on top of the framework to provide the console. Ideally this would >> involve a way to configure the framework so that the -console option just >> did what you need to get your bundles started as well as completely >> disabling the console support built into the framework. I think that is part >> of the solution proposed >> inhttps://bugs.eclipse.org/bugs/show_bug.cgi?id=169603 >> >> Tom >> >> >> >> <graycol.gif>"Kirchev, Lazar" ---12/02/2010 10:52:30 AM---For the extraction >> of the console in a separate bundle there is a bug opened: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=169 >> >> <ecblank.gif> >> From: >> <ecblank.gif> >> "Kirchev, Lazar" <[email protected]> >> <ecblank.gif> >> To: >> <ecblank.gif> >> Equinox development mailing list <[email protected]> >> <ecblank.gif> >> Date: >> <ecblank.gif> >> 12/02/2010 10:52 AM >> <ecblank.gif> >> Subject: >> <ecblank.gif> >> Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo >> >> >> >> >> For the extraction of the console in a separate bundle there is a bug opened: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=169603 >> and a patch is provided there. >> >> One of the reasons for considering the moving of the console out of the >> framework is that adding new features to the console while it is in the >> framework will increase the size of the framework. The current built-in >> console lacks telnet supportability features for example. Now if the console >> stays in the framework, it will not include such features. But such >> supportability features also improve usability. Probably we should provide >> them as an optional bundle - anyone who needs them to install this bundle? >> What I have prepared for the incubator is meant to run as a Gogo command, >> but it easily may be changed to support both cases – as a Gogo command, and >> the ConsoleSession interface available since 3.6. >> >> Also, currently the only way to run Gogo on top of Equinox is to start >> Equinox without the –console option, and make Gogo bundles initially >> started. So it is not possible to pass –console and start either one, or the >> other. Probably add an option to specify the console jar/jars, if a console >> different from the built-in should be started? >> >> Lazar >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf OfThomas Watson >> Sent: Thursday, December 02, 2010 5:50 PM >> To: Equinox development mailing list >> Subject: Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo >> We also must consider the amount of work it would take to extract the >> console out and test it properly. I am reluctant to do any of that work when >> we want to eventually replace the console implementation with the gogo shell >> and a bundle that bridges the old equinox command implementations to the new >> shell. >> >> Tom >> >> >> >> <graycol.gif>Jeff McAffer ---12/02/2010 09:37:45 AM---The disadvantage is >> usability. Right now you get equinox and run with -console and its all good. >> If we break it out you'll ha >> >> <34743407.jpg> >> From: >> <34519726.jpg> >> Jeff McAffer <[email protected]> >> <34743407.jpg> >> To: >> <34519726.jpg> >> Equinox development mailing list <[email protected]> >> <34743407.jpg> >> Date: >> <34519726.jpg> >> 12/02/2010 09:37 AM >> <34743407.jpg> >> Subject: >> <34519726.jpg> >> Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo >> >> >> >> >> >> The disadvantage is usability. Right now you get equinox and run with >> -console and its all good. If we break it out you'll have to get two bundles >> and make sure that the console bundle is started... >> >> We have thought about shipping two setups, one with the console and one >> without. That might work but we need to consider consumer confusion (which >> one do I get, which one do I have, ...) and the work required to >> setup/maintain the build. >> >> Perhaps the new starter kit direction we've been exploring could offer some >> help... >> >> Anyway, there is a lot of pressure to improve ease of use so we need to keep >> that in mind through these changes. >> >> Jeff >> >> On 2010-12-01, at 6:02 PM, Alex Blewitt wrote: >> On 1 Dec 2010, at 22:06, Thomas Watson wrote: >> There have been various discussions about replacing our framework console >> with something a bit more functional and flexible like apache gogo [1]. At >> this point in the Indigo release we do not plan to remove our own console >> for the Indigo release. Instead we will do what ever is required to enable >> the use of gogo on top of Equinox. We would like to use the incubator to >> allow this effort to mature and then re-evaluate the complete removal of our >> built-in framework console in a later release. Lazar Kirchev from SAP has >> been doing various experiments and investigations in this area. My hope is >> that Lazar will soon be in a position to contribute this work to the equinox >> incubator so that others can try it out on top of Indigo. >> >> Tom >> >> [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=317827 >> One other advantage would be in slimming down Equinox by providing the >> console in a separate bundle from the main OSGi runtime. >> >> Alex >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
