Skip to main content
Eclipse Monkey Proposal


The Eclipse Monkey is a proposed open source project under the Eclipse Technology Project to be split from the Eclipse Dash Project and to be based on the existing Groovy Monkey Project.  This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the newsgroup. 


Eclipse provides a flexible and extensible framework for third party tool integration, but the only way currently to extend its functionality is through the context of a bundle/plugin component.  The primary issue is that creation of a fragment or bundle can be heavyweight and forces the user to utilize Eclipse's self-hosting feature.  There must be a simpler, lighter and easier way for a power user/developer to extend/modify the current Eclipse workbench.  In particular, there is no defined way to script from within Eclipse.  This is what the new Eclipse Monkey seeks to address.  A simpler and catchier synopsis would be to say that the new Eclipse Monkey is aiming to give the Eclipse power user the power of Emacs without the LISP.


The new Eclipse Monkey seeks to address the following three scenarios:

  1. Eclipse Task Automation and Scripting
  2. Eclipse API Exploration
  3. Rapid Prototyping and Quick Development of new Eclipse Plugins.

Eclipse Monkey Lifecycle View: From script to full blown plugin
A user starts with a script that does something useful.  Eclipse Monkey provides easy ways to access it, modify it, to run it and to share it with others.  After some time, multiple scripts are written with functions that can be reused.  Library scripts are then written, simplifying the other scripts and providing for reuse.  After some more time, it is noticed that some of these library scripts are very useful and to take advantage of static typing/Java tooling those library scripts become DOM (Domain Object Model) objects deployed in a plugin.  Eventually the DOM plugin could become the basis of a fully functional Eclipse plugin, with UI elements, extension points, etc...

Eclipse Monkey seeks to make it as simple as possible to use to as large a potential audience as possible, it attempts this by the following:
  1. To be as language agnostic as possible.  If a JVM language has a BSFEngine implementation and can utilize the classloader passed into it, it can be used.  The Eclipse Monkey tool should not force a user into a new language to begin working.  Scripts written in one language should be able to invoke others written in another language.
  2. An editor with hippie completion and (to the degree possible) code completion.
  3. An outline view to show the user how the script is configured and what is available for use (DOMs/bundles/java packages).
  4. A DOM that enables a user to invoke another monkey script, in the workspace, via a URL or generated and fed as a string input.
  5. A DOM that allows a script writer to take an existing plugin project and hot-load it into the current existing Eclipse workbench instance.
  6. A console DOM that allows a script writer access to something like stdout for feedback.
  7. Language specific DOMs that enable Eclipse Monkey to leverage existing libraries for the user (ex. GroovySWT or JRuby Glimmer).
  8. Additional metadata keywords that enable filesystem jars, filesystem folders, workspace jars, workspace folders, workspace projects or existing workbench bundles to be added to a script's classpath at runtime.
  9. Add in shell support through use of Eclipse Monkey metadata as a template and the BSF support for consoles.

Proposed Changes

The new Eclipse Monkey tool will be based on the existing Eclipse Monkey's use of a metadata header (with additional keywords), but will be extended to use the Apache Bean Scripting Framework and the Eclipse Jobs API. 

  • Additional/Modified Metadata Keywords

The new Eclipse Monkey will modify this keyword to allow the user to specify the local variable name for the script, overriding the name defined in the extension point.  This will address potential variable name conflicts and give the DOM user/developer more freedom in choosing variable names.  Eclipse Monkey will also provide support by marking potential conflicts and offering quick fixes to address them.

This is a keyword that works in conjunction with the new Job keyword.  Exec-Mode allows the script writer to tell Eclipse whether to run the script as a foreground or background job.  The net effect is to determine if there should be a modal progress dialog shown to the user when the script is running or if it should be in the Eclipse progress view when running.

The Include keyword allows script writers to add class folders or jars from the workspace or filesystem directly to the classloader defined for the script.  For instance this allows script writers to leverage 3rd party libraries or java binaries in output folders directly.  The Include keyword is vital for allowing scripts to be used in prototyping.

The Include-Bundle keyword allows script writers to add bundle classloaders directly to the classloader of a script at runtime.  Eclipse Monkey will use the OSGi runtime to acquire the target bundle's classloader and then allow the script's classloader to delegate to it at runtime.  The net effect is to allow a script to be written such that if it were Java code directly embedded in one or more bundles.  The Include-Bundle keyword is vital to enable Eclipse Monkey's goals of task automation, Eclipse API exploration and rapid prototyping.

The Include-Project keyword allows script writers to add Java workspace projects directly to the classloader of a script at runtime.  Eclipse Monkey will use the JDT to interrogate the project for its resolved classpath and pass that information onto the classloader of the script at runtime.  This feature will not be enabled for Eclipse RCP apps that are lacking both the Eclipse Platform and JDT.  Future enhancements could allow for Eclipse Monkey to be able to determine if a project is a plugin and then be able to load the bundle via the bundlerDOM, run the script and then unload the bundle after its completion.

The Job keyword allows script writers to specify the kind of Eclipse job that the script is to run in.  Current valid values are Job, WorkspaceJob, UIJob and default (empty string) maps to Job.

The LANG keyword allows script writers to specify the language the script body is to be written in.  Current valid values are Beanshell, Groovy, Ruby and default (empty string) maps to Groovy.

The Menu keyword allows script writers to specify the pulldown path to access the script via the monkey menu.

The full path of the script in the workspace.

  • Apache Bean Scripting Framework
The Apache Bean Scripting Framework enables the use of any JVM (Java Virtual Machine) Language that has a compatible BSFEngine implementation.  As of right now the existing Groovy Monkey project allows scripts to be written in either BeanshellGroovy, or Ruby.  The first release of the newly constituted Eclipse Monkey will target the aforementioned languages but also will target ECMAScript(JavaScript) and Python.

  • Eclipse Jobs API:
An Eclipse monkey script will be run within the context of an existing Eclipse Job. 

Relationship with other Eclipse Projects

Eclipse Monkey is meant to enable scripting on the entire range of Eclipse platforms.  A core plugin should allow for scripting on a base Equinox OSGi container (+org.eclipse.core.runtime/resources) based application.  A core and core UI plugin should allow development of Monkey scripts on Eclipse RCP platforms.  Finally, full editor support and features should be allowed for Eclipse platforms that contain the JDT.  As more and more of the full Eclipse SDK is available, more functionality would be available from Eclipse Monkey.


We propose this project should be undertaken as a Technology project rather than as part of the Eclipse Platform. Being a Technology project gives it room to experiment without disruption to other Eclipse Platform development work.

Finally, since Technology sub-projects are not meant to be ongoing, we foresee three possible evolutionary paths for the subproject:

1. The project is merged back into the mainline Eclipse Platform top-level project.
2. The project is moved to a permanent state as a Tools Platform project.
3. The technology proves to be insufficient for Eclipse and the work is set aside.

These paths are not mutually exclusive. Some combination of some or all of these paths may be the result of the work done in this project. 

Proposed initial committers

  • James E. Ervin, Independent Software Engineer
  • Others welcome

Interested parties

Code Contributions

James E. Ervin is offering Groovy Monkey as an initial codebase (see

Tentative Plan

Development with Groovy Monkey is on-going, if given the green-light, work will cease on that project and the first version of the new Eclipse Monkey would follow relatively quickly.  Given the number of potential languages to use as input and the potential number of features, releases should occur on a regular six week schedule.

Back to the top