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
|------------>
| From: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------------|
|"Kirchev, Lazar" <l.kirc...@sap.com>
|
>-----------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------------|
|Equinox development mailing list <equinox-dev@eclipse.org>
|
>-----------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------------|
|12/03/2010 03:58 AM
|
>-----------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------------|
|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: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] 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 in
https://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> <ecblank.gif>
From: "Kirchev, Lazar" <l.kirc...@sap.com>
<ecblank.gif> <ecblank.gif>
To: Equinox development mailing list <equinox-dev@eclipse.org>
<ecblank.gif> <ecblank.gif>
Date: 12/02/2010 10:52 AM
<ecblank.gif> <ecblank.gif>
Subject: 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: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas 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> <34519726.jpg>
From: Jeff McAffer <j...@eclipsesource.com>
<34743407.jpg> <34519726.jpg>
To: Equinox development mailing list <equinox-dev@eclipse.org>
<34743407.jpg> <34519726.jpg>
Date: 12/02/2010 09:37 AM
<34743407.jpg> <34519726.jpg>
Subject: 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
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
