Eclipse Web Interface
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, will issue the command received to one of the currently running Eclipse instances.
- Utilizing NanoHTTPD for this purpose. For now it helps to reduce the complexity of the project. Perhaps, as secondary goal, the code can be adapted to use one of the OSGi Http Service implementations. (org.eclipse.equinox.http.jetty or org.eclipse.equinox.http)
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 :-)