Support the creation of builder plugins for a language from a different project.

My use case: add a builder for NaBL that provides an alternative implementation.

For the time being, I would be happy if it would only work in a development set-up where I have both projects checked out and built in Eclipse (if that would simplify things).

Submitted by Eelco Visser on 14 July 2014 at 12:01

On 14 July 2014 at 12:23 Vlad Vergu commented:

Eclipse-wise this is not hard to realize. Plugin A (the language) can publish an Eclipse extension point for builders. Plugin B (the extender) can extend this extension point. Plugin A can query the Workbench for implementors of the extension point. The extension points schema can require the extender to specify locations of ESVs and Jars. We can have a setup where the extender provides a minimal ESV which we pack and read. There’s already syntactic support in ESV for extensions but no attached logic AFAIK. The question is the issue of compilation of the extender’s Stratego code which will likely at least depend on the signatures of the extended language. This has to be resolved by compilation as library, without the inclusion of the extended language in the extender’s binaries, as to allow for multiple extenders. The extended language at runtime loads its own jars/ctrees and those of the announced extenders.


On 14 July 2014 at 18:43 Guido Wachsmuth commented:

I think this is more a language registry issue than an Eclipse extension point issue. In earlier discussions with Gabriël in Delft, we had the idea of two different kinds of language projects.

  1. Similar to the existing projects, a language project provides syntax and static analysis for a language.
  2. A new kind of builder project allows to provide builders and menu entries for (potentially multiple) languages.

Currently, we register providers by language, making strategies from these providers available to all builders of the language. This is actually not needed. On the other end of the spectrum, each builder could have its own provider, hiding its strategies from other builders. In most cases, you want something in between, where you provide several builders for several other languages. Take for example Augusto’s work. He could have a single builder project, which provides builders for SDF3, NaBL, TS, and DynSem.

The technical solution is probably similar to the one Vlad suggests. Instead of having a notion of extension in ESV, this would require means to specify builders independent of languages (but hooks to connect them to existing languages).

AFAIK, Gabriël planned to work on this during his internship.


On 15 July 2014 at 05:09 Gabriël Konat commented:

We shouldn’t use the Eclipse plugin mechanism to realize this, because that would make it unusable outside of Eclipse. Configuration in ESV and an implementation in Spoofax and Sunshine, or in ‘Spoofax core’, will make it usable everywhere.

It is both a language registry and compilation issue. The language registry would provide an implementation to add builders to another language. But the compilation problem that Vlad highlights will still be there. If you want to add a builder that transforms SDF2 into SDF3, you somehow need to depend on the Stratego ctree/jar, and possibly other parts, of both SDF2 and SDF3. Currently there is no nice way to do this, other than copying these things from the SDF2 and SDF3 projects into the extender project.

I will work on the language registry part at least, but I think it already supports these use cases, just that we do not use them.


On 14 September 2015 at 18:03 Peter Mosses commented:

(I know very little about Eclipse and builders, and I’m not sure whether this query is related to Eelco’s proposal – kindly remove it if not.)

I have a folder containing files in a language called CBS, and an editor project with a button to generate SDF3 files from CBS files. I’d like to automate the generation, so that building a project visits all the CBS files in the folder, and generates new SDF3 files wherever they are needed, before proceeding with the rest of the build.

I guess this could be automated externally using Sunshine and a command-line script, but I’d prefer to incorporate it directly in a Spoofax editor build file. Is that possible?

Log in to post comments