Jump to: navigation, search

Difference between revisions of "An auto-configuration plugin for Eclipse"

(Applications / Services that should be detected)
(Remove a dead linke.)
 
(48 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
==About==
 +
This project aims to design an Eclipse plugin that allows the binaries required by other Eclipse plugins to be automatically located. The source code shall be released under the Eclipse Public License. This is one of the selected projects for the  [[Google Summer of Code 2007|2007 Google Summer of Code]]. The original application can be found [[autoconf plugin proposal | here]]. All Bugs filed against Discovery are available in [https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=SoC%20Discovery Bugzilla].
 +
 
Project Lead:
 
Project Lead:
*Ogechi Nnadi (IRC: onnadi3)
+
*Ogechi Nnadi (IRC: onnadi3) Blog: [http://www.perilsofeclipse.blogspot.com  The Perils of Hacking Eclipse] E-mail: onnadi3 AT mail DOT gatech DOT edu
  
 
Mentors:
 
Mentors:
Line 6: Line 9:
 
*Remy Chi Jian Suen (IRC: rcjsuen)
 
*Remy Chi Jian Suen (IRC: rcjsuen)
  
This project is one of the selected projects for Google's Summer of Code program in [[Google Summer of Code 2007|2007]]. The original application can be found [http://code.google.com/soc/eclipse/appinfo.html?csaid=80E216D7E2DC218F here].
+
==Downloads==
 
+
===Update Site===
 
+
Use this if you simply want to test out the JRE Discoverer, or if you do not care about viewing the source code
==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).
+
[http://wiki.eclipse.org/Image:Update_site_20070815.zip JRE Finder example]
  
How it'll be accomplished: At its core, this plugin will be composed of a
+
===Source Code===
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.
+
The most up-to-date version can be found in the CVS repository at <b>soc.eclipse.org:/cvsroot/soc/org.eclipse.soc.discovery</b>. An old version of our code is currently hosted in the eclipse-incub project at SourceForge, under the module name, [http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/sevice-discovery/ service-discovery].
  
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.
+
==Bugs==
 +
[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=SOC&component=org.eclipse.soc.discovery&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Open bugs against Discovery]
  
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.
+
[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=SOC&component=org.eclipse.soc.discovery&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Resolved bugs in Discovery]
  
==Deliverables==
+
==Meetings==
 +
We meet on Saturdays at 9:30am EDT/3:30pm CEST in the #eclipse-soc channel on irc.freenode.net.
 +
Meeting has been rescheduled permanently to Mondays at 11:30amEDT/5:30pm CEST.
  
==Terminology==
+
Here are [[auto-conf meeting agenda | open issues to discuss]].
  
==Use cases==
+
Here are our current [[auto-conf meeting logs | meeting logs]]. Here are the [[auto-conf meeting backlogs | older logs 1]], [[auto-conf meeting backlogs2 | older logs 2]], [[auto-conf meeting backlogs3 | older logs 3]].
===Applications / Services that should be detected===
+
*JDK/JRE, GCC, Python, Perl, etc.
+
**Blobs of documentation (javadoc, PoD), 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==
+
[[Category:SOC]]

Latest revision as of 16:37, 14 October 2007

About

This project aims to design an Eclipse plugin that allows the binaries required by other Eclipse plugins to be automatically located. The source code shall be released under the Eclipse Public License. This is one of the selected projects for the 2007 Google Summer of Code. The original application can be found here. All Bugs filed against Discovery are available in Bugzilla.

Project Lead:

Mentors:

Downloads

Update Site

Use this if you simply want to test out the JRE Discoverer, or if you do not care about viewing the source code

JRE Finder example

Source Code

The most up-to-date version can be found in the CVS repository at soc.eclipse.org:/cvsroot/soc/org.eclipse.soc.discovery. An old version of our code is currently hosted in the eclipse-incub project at SourceForge, under the module name, service-discovery.

Bugs

Open bugs against Discovery

Resolved bugs in Discovery

Meetings

We meet on Saturdays at 9:30am EDT/3:30pm CEST in the #eclipse-soc channel on irc.freenode.net. Meeting has been rescheduled permanently to Mondays at 11:30amEDT/5:30pm CEST.

Here are open issues to discuss.

Here are our current meeting logs. Here are the older logs 1, older logs 2, older logs 3.