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

Reply via email to