The Summer of Code goes on

I feel the guilt because of not posing about the GSoC event so far. Perhaps should start blogging more about what I am doing at all.

For the project I have 3 goals now, sorted by priority:

1. Provide the ability to write the plug-ins in a scripting language.
Basically it means that a new plug-in could be implemented in any scripting language, supported by JSR-223. My mentor, Wayne, purposed a tricky solution to bind a script to a popup action using a syntax feature for the action definition in plugin.xml:

<action
  class="scriptexecutor.actions.ExecuteScriptAction:my.script"
  icon="icons/sample.gif"
  id="scriptexecutor.actions.SampleAction"
  label="&Sample Action"
  menubarPath="sampleMenu/sampleGroup"
  toolbarPath="sampleGroup"
  tooltip="Hello, Eclipse world"/>   

An action class ExecuteScriptAction will be provided by the supporting plug-in, and my.script is something that is implemented by the new plug-in developer.
ExecuteScriptAction will act as a facade to the scripting world, setting the required variables to the script context and running the script itself, using javax.scripting API.

public class ExecuteScriptAction 
  implements IWorkbenchWindowActionDelegate, 
  IExecutableExtension {

  private URL script;

  ...

  @Override
  public void setInitializationData(IConfigurationElement config, 
    String propertyName, Object data) 
      throws CoreException {
    Bundle bundle=Platform.getBundle(config.
           getContributor().getName());
    Enumeration entries = bundle.findEntries("/", 
           data.toString(), true);
    if (entries == null) return; // The script wasn't found.
    URL entry = null;
    if (entries.hasMoreElements()) entry = 
          (URL)entries.nextElement();
    this.script = entry;
  }

  ...
}

So basically, setInitializationData() sets the parameter to the action class and after that we can do whatever we would like to with the script file when IActionDelegate#run() is called for this class. Most probably I will have to pass a pointer to the current workbench to the script context, like Eclipse Monkey does.

2. Enable custom processing for plugin.xml, to be able test the new plug-ins without starting the 2nd eclipse instance.
This was actually the initial idea, but it seems that enabling scripting for the bundled plug-ins is more valuable. Probably it is better to bundle this functionality as a separate plug-in even. Processing plugin.xml will involve parsing the configuration and registering the extensions to the same workbench where the brand new plug-in is being developed.

IExtensionRegistry registry = Platform.getExtensionRegistry();
IExtensionPoint point = registry.getExtensionPoint
               (EXTENSION_POINT_ID);
IExtension[] extensions = point.getExtensions();

for (IExtension element : extensions) {
   // register the extension
}

3. The console, for providing the interactive (re)loading of the plug-in. I'm not very sure yet, will it be a Apache Derby ij style console, or will it be a set of controls, but definitely it is a good feature to implement to smooth plug-in prototyping.

Now, after a good vocation in Croatia, will have to speed up things a bit to be in time with the implementation.