-
Notifications
You must be signed in to change notification settings - Fork 3
The idea of splitting the features of the IDE into separate bundles was considered, but unfortunately dropped because of pragmatic reasons. These include:
- The plugin definition mechanism of Eclipse requires so much boilerplate and crossreferences that at the desired level of granularity there would be a loss in maintainability which may not justify the gain.
- A more lightweight solution would be fragments but they can't depend on each other which would be sometimes necessary.
- It is not straightforward to contribute more bindings to an existing Guice module via plugins.
- When defining perspective extensions independently, there is not as much control in the precise result.
Xtext is a cutting-edge framework for building IDEs for domain specific or general purpose languages in Eclipse. Of course, as with most technological decisions, there were alternatives to choose from. The first one was IMP, but it was not chosen because it's more generic and thus more complex - Xtext is more appropriate for incremental grammar evolution with short turnarounds. The other one, EMFText is more similar to Xtext in this aspect, but - and this is the main cause - Xtext (besides the greater flexibility via dependency injection and better integration with existing modeling technologies) can infer the abstract syntax from the concrete, which is a huge advantage because there is no high-level metamodel for LilyPond, and it would be difficult and tiresome to create manually.
Besides, Xtext is feature-rich while integrating well with other Eclipse projects, has excellent code quality, and it suits my needs better in this specific use case (namely LilyPond). Of course, if you plan to develop Eclipse tooling support for your favorite DSL, you should consider using any of these technologies based on your requirements.