Difference between revisions of "Eclipse Web Interface"
|Line 104:||Line 104:|
The other option is to get the [[#Source Code]] and install the plug-in manually.
The other option is to get the [[#Source Code ]] and install the plug-in manually.
Revision as of 07:37, 23 August 2007
This project aims to add the ability to externally invoke commands in Eclipse via a web browser.
For example, this could enable a site to provide a link which would cause Eclipse to fetch and open a source code file in a single click. A sample link might look similar to the following:
<a href="http://localhost:56789?command=open_file&filepath=http://someWhereOnTheWeb/foo.java">open this file in Eclipse!</a>
Eclipse will listen for these requests and, when received, invoke the command in one of the currently running Eclipse instances.
Note: just to avoid any confusion, this example assumes that an "open_file" command has been written which supplies the aforementioned functionality.
- NanoHTTPD is currently being utilized for this purpose as it is a less complex alternative to using one of the OSGi Http Service implementations (org.eclipse.equinox.http.jetty or org.eclipse.equinox.http). See bullet in secondary goals.
- The Platform Command Framework is being looked at as a means for accomplishing this.
- this does not include support for headless Eclipse instances
Firstly, to have the server load on startup the the startup extension point will be used. This startup code will then start an eclipse job which will run in the background and behave as a wrapper around the web server.
The wrapper will do the following
- check if any commands have been received by the server
- if commands exist then for each command
- if a handler exists for the command then forward the parameters to that handler
Dealing with multiple Eclipse instances
Special handling is necessary when dealing with multiple instances of Eclipse. For example, when a command 'foo' is received (e.g. http://localhost:34567?command=foo) and there are two or more instances running, which both support the 'foo' command, which instance should execute 'foo'?
One way to handle this could be to have one Eclipse instance act as a sort of 'main hub'. To clarify, all commands would first be received by this instance. When necessary, this main instance would forward commands to other instances. The instance that a command gets forwarded to would be chosen by the user via a dialog which lists all viable Eclipse instances (i.e. those which support the command).
The first Eclipse instance loaded will utilize the default port (e.g. 34567) and act as the main instance as described above.
Then, when a second(or third, fourth, etc.) instance is launched it tries to obtain the default port. Since it will not be able to(because it's already in use by the main instance) it chooses a random unused port and then registers itself with the main instance which will always be found on a defined default port (34567 in this case).
e.g. [Eclipse instance #2] --> http://localhost:34567?command=registereclipse&port=56789 --> [main Eclipse instance]
Now the main instance is aware of the second. At this point the main instance can request a list of commands supported by the second instance. This will be useful for disambiguating which Eclipse instance should handle a command when there are multiple instances which can handle the same command.
So when the main instance receives a command a dialog can be shown which will list all the instances supporting the command. The user then picks which instance the request should be forwarded to.
What should be done when an instance terminates? One approach is to require that all non-main instances send ping-like messages(e.g. resending the registereclipse command) to the main instance at a regular interval. The purpose of these messages would be twofold:
- It would allow the main instance to keep track of 'alive' secondary instances.
- It would allow a secondary instance to detect if the main instance has terminated. The discovering instance could then take over listening on the default port and become the new main instance.
- [EditorMgmt] Need ability to open a file in eclipse from the command line (see bug 4922)
- [launcher] way to pass arguments from launcher to a running application instance (see bug 178927)
- this could be used as the extension associated with an 'open' command
- Windows Explorer Shell Extension Possible? (see bug 183266)
- Provide an external program to run commands in a running Eclipse instance (like gnuclient) (see bug 186147)
Tentatively as follows:
- Analysis (up until May 28):
- This phase will involve interaction with the mentor to estimate the exact requirements of the project and research in order to gain more familiarity with the Eclipse framework. It will also involve setting up the project infrastructure such as the code repository.
- Development Part I (May 28 - June 21):
- This phase will involve the development of the code which listens for and responds to command execution requests.
- Development Part II (June 22 - July 16):
- This phase involves the creation and implementation of a generic way to add and remove commands.
- Testing and Wrap-Up (July 17 - August 28):
- This phase involves thoroughly testing each aspect of the finished project and tying up any loose ends.
Some intermingling and modification of these phases will most likely be necessary :-)
The simplest installation route is to use the Eclipse update manager (Help > Software Updates > Find and Install...) and then add the following remote site:
The other option is to get the source code and install the plug-in manually.
Once you've got the plugin installed, to quickly see some commands in action, here are a few sample links you can try:
To specify a command yourself, point your browser to:
Simply replace IDofCommand with the identifier of the command you want to run. As well, if applicable, replace parm1, parm2, etc. with valid parameter names and values.
Note: In the event a command actually has a parameter named "command", the first "command" value from the left will be used as the command ID and the other will be used as a parameter. So, to be safe, make sure the command you want to run is specified before any of it's parameters.
Contributing your own commands
To contribute your own command, your plugin must:
- define a command via the org.eclipse.ui.commands extension point and
- define a handler via the org.eclipse.ui.handlers extension point
Here's a sample plugin.xml of a plugin reachable through the Web Interface:
<plugin> <extension point="org.eclipse.ui.commands"> <category id="org.eclipse.soc.ewi.examples.commands" name="Example Commands"> </category> <command categoryId="org.eclipse.soc.ewi.examples.commands" description="Open a file in the active workbench window." id="org.eclipse.soc.ewi.examples.commands.openfile" name="Open File"> <commandParameter id="path" name="File Path" optional="false"> </commandParameter> </command> </extension> <extension point="org.eclipse.ui.handlers"> <handler class="org.eclipse.soc.ewi.examples.openfile.OpenFileHandler" commandId="org.eclipse.soc.ewi.examples.commands.openfile"> </handler> </extension> </plugin>
You would invoke the above plugin by targeting: