Re-Inventing the Wheel: Experiences in Building an IDE using Eclipse Rich Client Platform

Simon Zambrovski

IDEs · Long
Thursday, 13:30, 40 minutes | Schubartsaal

7
·
8
·
9
·
10
·
11
·
12
·
13
·
14
·
15
·
16
·
17
·
18

Re-Inventing the Wheel: Experiences in Building an IDE using Eclipse Rich Client Platform

Abstract

The Eclipse IDE provides a rich set of tools for working with different languages and platforms. Various articles discuss its extensibility and promote the usage of the platform infrastructure for the creation of own language integration, which can vary from a simple support of additional commands, editor integration to debugging support and other advanced features. In any case, the result is the Eclipse IDE with the plug-ins for the new language. In some cases the full functionality of Eclipse IDE is not desired and is even hindering the inexperienced user learning the new language. In such case there is a trade-off between using the Eclipse IDE with language plug-ins versus creation of the own Rich Client based on the Eclipse RCP. In this talk, the experiences gathered during the construction of the Eclipse-based rich client application, which offers the IDE for the specification language TLA+, are presented.

Content

In the previos nine month I was building an IDE for an existing language (TLA+). During this time I gathered a lot of experience I would like to share in this talk. Especially, I would like to go through the various steps of creation of an IDE for a language. In doing so I focus on a creation of an stand-alone RCP rather that just an Eclipse IDE plug-in. Apart from trivial issues like customization of UI I would like to cover generic issues which may apply to most language-integration building scenarios.

Resource management / Workspace concept

Eclipse IDE provides a standard implementation for the workspace and resources which can be used. Thus, there is a couple of restrictions that has to be accepted in the standard case including: These restrictions might be not acceptable for your IDE, so I\'ll show strategies to implement around this. In the solution I implemented, the workspace root is not used as a container for the project folders, and the project folders are not container for the project files. In addition, I\'ll show how the Common Navigator Framework can be used in order to show custom view on the resources.

Editors

Almost every language integration requires a good editor support. Even more, most language plug-ins provides the editor at first place. The standard features of editors are usually: auto-completion, syntax-highlighting, hyperlinking, content assist and others. The Eclipse editor framework provides a powerful API to implement these features. Thus, most of the features depend on the good parsing facility for the target language. I\'ll explain the options available (parser generator frameworks, parser generators, manual parsers). Especially, I would like to share some experiences about creating editor support for a real language, and not a dummy sample which is constructed in order to match the parser generator framework perfectly.
Creation of structural form-editors is a real alternative to creation of text editors. Eclipse Forms is a powerful technology which can be used for this purpose. It can be extended by a framework for validation of the data entered into the fields and combined for example with a data binding technology. In the implemented solution, the form-based editor for launch configurations has been constructed using a simple validation framework and custom data binding framework.

Builders

Eclipse introduces a notion of the project builder, which can be attached in order to execute tasks on resources. Even being a very powerful framework, there are some important assumptions it makes about the process of building. For example the builders are invoked very often and the information about what triggered the build is not available. Incremental builders must be quick (or better immediate). I would like to share some thoughts about how to integrate and build custom builders.

Launching and Long running tasks

Eclipse offers various ways to lunch long running actions. The launch framework offers a good starting point for adaptation to custom launch types. By the fact of clean separation between the UI and Core parts it allows to implement another representation of Launch Confoiguration editor. Launch framework can be effectively combined with the Jobs API. Thus, usage of jobs is a non-trivial task, especially because of the cuncurrency and synchrnoization issues related to the jobs modifying the workspace. I would like to show some details on how jobs can be used for workspace modifications. I\'ll describe some ways to aviod concurency problems related to resources. In the implemented solution I implemented custom launch types, custom launch config editor and starting jobs which are used to encapsulate the long running tasks.

Simon Zambrovski was spending the last nine month at Microsoft Research Sillicon Valey, California, USA and worked with Leslie Lamport on a development of Eclipse-based IDE for a formal language called TLA+. He is an author of several articles and is interested in various Eclipse technologies like modeling, IDE and others. He spend about three years on a definition of a modeling methodology for SOA-based architectures at TUHH, Hamburg, Germany and worked for large IT consulting company Lufthansa Systems (industry solutions, aerospace) in Hamburg, Germany.

brox logo

bandxi logo

empolis logo

ibm logo

ww-im logo

sigsdatacom logo

bsi logo

purple scout logo

froglogic logo

microsoft logo

Eclipse Magazin logo

osbf logo

bredex logo

sopera logo

microdoc logo

oreilly logo

instantiations logo

cloudsmith logo

compeople logo

itemis logo

dpunkt logo

eclipsesource logo

sap logo

oracle logo

vogel logo

open-xchange logo

Actuate logo


report a problem with this page