Pages

Wednesday, July 4, 2007

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.

No comments:

Disqus for Code Impossible