Jump to: navigation, search

An auto-configuration plugin for Eclipse

Project Lead:

  • Ogechi Nnadi (IRC: onnadi3)

Mentors:

This project is one of the selected projects for Google's Summer of Code program in 2007. The original application can be found here.


About

Abstract Many Eclipse plugins require the user to specify the location of certain programs or services running locally in order for them to work. Having humans do this is unnecessary since services are commonly installed in only a few fixed locations. Thus I propose writing an Eclipse plugin that uses a number of heuristics to locate local services that other Eclipse plugins need. I also propose including a number of utilities that enable developers to easily write, extend, and distribute these service 'scanners.'

Detailed Description Motivation: Many Eclipse plugins need to interact with programs that are not part of the Eclipse ecosystem. Plugins such as the Ruby, C/C++, and PHP Development Tools all require the user to specify the location of a language interpreter or compiler. Often, this configuration is unnecessary since, for instance in Linux machines, the GNU C compiler binary is almost always /usr/bin/gcc. Heuristics like this do not have to be for programs only. What port will a Web server on your local machine be running on? Most Likely ports 80 or 8080, so the IDE might as well scan them and offer you a list of servers with which to debug your PHP script, for example. All in all, it is possible to automatically discover the services running on a machine and to automatically configure other plugins to use these services (think Autoconf for Eclipse).

Benefits: Once plugin writers start to depend on this "autoconfiguration", the plugin users will gain 2 things: 1) It will reduce the time it takes to run "Hello, World" applications for new plugins. Once the necessary software is installed, click on a "Detect required services" button will do the configuration for them and allow them to move on to the interesting task of running applications. 2) It will reduce the tedium of reconfiguring plugins whenever a newer version of a program/service is installed, or when setting up a development environment on a new machine.

Objective: Thus, I propose to write an Eclipse plugin that discovers services running on a system and then publicizes these services to other Eclipse plugins using the Prefs API; the services "scan" will be run whenever Eclipse is started. The plugin will also publish an API for other plugins to request a scan for particular services even after the Eclipse has been started.

In addition, I propose creating a mechanism for easily extending these service "scanners", creating new ones, and publishing the whole lot. This mechanism will consist of 1) An interface for viewing all the scanners in an Eclipse installation, 2) A utility for packaging scanners into an archive format (perhaps JAR) so that it can easily be distributed, and 3) Another utility for unpacking these scanners and installing them.

With these utilities in place, the work of developing recognizers can continue even after the Summer of Code is over (yay, open source).

How it'll be accomplished: At its core, this plugin will be composed of a table of service names, each with a list of scanners for that service. Each scanner returns 0 or more strings representing a resource identifier. When a plugin requests locations for, say, the gcc compiler, the scanner plugin runs all the scanners listed under the name "gcc" and returns it to the requester.

I chose to store a list of scanners so that developers can easily extend others' work without touching existing code. For instance, If someone discovers a new heuristic for finding a service, they can write their own scanner and when it is installed, it will add the list of matches it finds to the matches found by other scanners.

Note also that I have refrained from using version numbers as an extra identifier for locating services. This is in following the Autoconf tradition of testing features and not versions, and will result in a simpler implementation.

Deliverables

Terminology

Use cases

Applications / Services that should be detected

  • JDK/JRE, GCC, Python, Perl, etc.
    • Blobs of documentation (javadoc, PoD, Doxygen), preferably linked to the resources they document
  • Apache Http server, Apache Tomcat, Jetty
  • bzip2,gzip,rar,arj,... (for deployment and browsing into archives)
    • An EFS provider that allows browsing into such archives like folders might be a nice side project
  • Cygwin (including auto-detect of cygwin mount points and path translation)
    • An EFS provider that shows the cygwin local filesystem might be a nice side project

Architecture