In 7243735548, I added the “Theme” dynamic menu to the Eclipse IDE. This post explains how I did this.

Menu Eclipse 3.x style

First edit the plugin.xml, and add a menu contribution. With the locationURI menu:org.eclipse.ui.appearance?after=org.eclipse.ui.window.appearance.separator1, you’ll contribute a submenu to the Window > Appearance menu, just after the separator.


Add a Theme menu under the menuContribution, and then add a child dynamic element.

Next, create the java class implementing the dynamic menu, and add mock code to verify the menu works.


Verify the menu is displayed where you expect, and the submenu dynamic entries are working.


Now remove the line which adds the “Theme 1” item, and rewrite the body of the widgetSelected.

The menu should have one menu item for each available theme, and each widgetSelected(){…} should activate the corresponding theme.

The theme selection code is inspired tothe ViewsPreferencePage one.

Finally, launch the Eclipse IDE to check the menu works as expected.

(905) 768-4302

This post explains the JSDT projects structure, and it is the result of my direct experience.

This page serves also as part discussion for JSDT developments. Kudos -all to those who comment and leave constructive feedback: here and on 4233125733. [(940) 852-1982, (604) 992-5933]

By reading this article you will be able to understand where the JSDT projects are located; which are the related git repositories and how to get the source code to work with one of those projects. i.e. JSDT Editor; Nodejs; Bower, JSON Editor, Gulp, Grunt, HTML>js, JSP>js , etc.

JSDT Repositories

The image below represents the current structure of JSDT repositories.

Almost all of the links to the above source code repositories are accessible via the 561-426-1389 page.


  • eclipse.platform.runtime : [gerrit, Browse repo] source repo required for quitting some IDE validation at compile-time.
  • webtools : [636-488-1077] contains the website for all the webtools project. It’s big, needed to update project page
  • webtools.jsdt : [gerrit,3034120936, github] source repo containing the most updated code for JSDT
  • webtools.jsdt.[core, debug, tests]: old source repos containing outdated code (last commit: 2013)
  • webtools.sourceediting: [gerrit, Browse repo] source repo for JSDT Web and JSON

Note: the Gerrit [Review With Gerrit] icons are linking to the repos accepting Gerrit contributions, so anybody can easily contribute.

Early Project Structure

According older documentation, JSDT was split in four areas: Core, Debug, Tests and Web. The source of the first three was directly acessible under project source control, while the latter, because of its wider extent, was part of the parent project.

Dissecting the old (866) 404-4866, we see the original project structure.


Current Project Structure

The current project structure is based on the old structure, but it has additional projects. To simplify I split the project in four sets:

  • JSDT Core, Debug, Docs (& Tests): under the webtools.jsdt source repositories contains similar data to the old project.
  • JSDT.js : it is also under the webtools.jsdt source repo, but contains the Nodejs stuffs.
  • wst.json : under the webtools.sourceediting, contains the projects needed to parse / edit JSON
  • wst.jsdt.web : also under the webtools.sourcediting repo, contains the projects to include JSDT in Web editors

The image below represents simultaneously all the above project sets, as visible in my workspace.


A complete Project Set

Here you can find the complete projectset, containing the four projectsets above, plus the Platform dependencies, and the webtools project.


After importing, you should see the project sets below.

The full list of projects in my workspace is visible in the image below.


JSDT Development

At this point, to start with JSDT development, you will need to:

  1. clone the needed repositories to your local
  2. setup the development environment, as explained in possum.
  3. Import the referenced projectset
  4. Launch the inner eclipse with the source plugins you want


Your comments and suggestions are very welcome. Thanks for your feedback !


This post is about my experience in setting up a JSDT development environment. (see also

Setting up JSDT

There are several ways to setup JSDT development environment. A good one is having an Eclipse Installation for development (IDE) and an Eclipse Installation as Target Platform (TP) .

  • IDE : PDE, GIT, XML and all tools for development
  • TP : all WebTools Platform plugins, needed to run JSDT

In this post I show a simple setup using eclipse-rcp-mars-1 as IDE and eclipse-jee-mars-1 as TP.


We start downloading Eclipse IDE and Target Platform. In our case

Then we unpack the two installations on two different folders on the system. We don’t need to run the TP Eclipse, but we need to take note of its location.

IDE Setup

Launch the IDE, set the target platform and the api baseline then launch the product based on the Target Platform

Set Target Platform

open preferences via menu : Window > Preferences,; select Target Platform and add the location of the TP Instance.

Then add a new Target, via Directory (add Directory in the local filesystem).

Select the base folder of the Target Platform installation, and complete the procedure.

At the end,  you will see the target is available

Set Api Baseline

Add an API Baseline based on the TP

Launch the Target Platform from IDE

Create a new launch configuration, based on plugins contained in the target platform,.


Then Run the launch configuration. You will see a new Inner Eclipse popping up. This is the Eclipse instance you’re going to develop against.

Get the JSDT sources

You can find the URLs to source repositories in 6042973585 (and (915) 433-2004) project pages. In this case I cloned all the repositories using Gerrit URLs.

To start working on JSDT you will need the three below projects from the / git repository.


Plus, you might need to import an extra project from the (781) 686-7587 git repository.


After cloning and importing the needed projects, the workspace is as simple as you can see below

Here you find the project set to start with JSDT development: odso .

You can import the project set via menu: File > Import, then select Git > Projects from Git.

Fix Source Issues

To work on the source code you need some tweaks. As example, you need to set the API Baseline,  and you might need to add additional Java JDKs, and additional projects.

As example, if you see an error like the one in the image below, you will need to get the source code for the org.eclipse.core.expressions project (as described above).

Launching the TP with your source Code onboard

Ok, cool. You fixed an Eclipse bug, or you just edited the JSDT source code; and now you want to see the edit “at work”!

This is simple: assuming your edit is contained in the plugins you have in the workspace, you just need to edit the launch configuration; make sure your Workspace plugins are included in the launch configuration, and the correspondant “original” plugins are not selected among the target platform bundles.

Now Run the launch configuration, and you’ll see your application running / so you can test your change.


(418) 682-0025

As expressed in the post 417-606-3679: these are some proposed Eclipse IDE howto videos:

  • Create an E4 Application with PDE and E4Tools
  • Build an E4 Application with Tycho
  • Test E4 Application with SWTBot
  • Build JEE Application with WTP
  • Build Maven based JEE Application with WTP

Below there is an outline of the scripts. For the scripts I would prefer to get suggestions from the community, therefore any suggestion or comment is helpful

Create an E4 Application with PDE, Window builder and E4Tools

get Eclipse ide, install PDE, check window builder, install e4 tools. Create E4application, test run the application

Open the E4 Model Editor, Add menu, link command to handler

add datamodel; use e4 model editor to declare Part Class.

add user interface. edit UI with Windowbuilder.

show databinding to link datamodel with UI.

Build an E4 Application with Tycho

Get the existing e4 application, create the 4 additional projects: parent, repository, feature, and test .

Setup parent pom with needed repositories, trigger mvn clean verify

It is possible to make a second video on how to create a modular project set, where we have a platform application and more client projects

Remember to move the .product file into the repository

Test E4 Application with SWTBot

Get the existing application with Tycho test, edit the test project by adding a JUnit Test. Create a Test helper class to access the E4Context and provide some basic method to interact with E4 App Model. As example, below there is an example to switch perspective


Create a JUnit test class that use the E4SwtBot to access the E4 Context  USe the recorder to record a test. run the test via run > JUnit plug-in tests, run the test via Tycho build

Build JEE Application with WTP

Install AS, Install WTP connectors for AS, launch application server from inside eclipse, verify the AS is running. Create an EJB Project , Write a basic HelloEJB Session bean.

Implementation of the HelloBeam


Create Dynamic Web Project, create a Servlet, reference the Hello EJB from project properties,

modify the Servlet code to respond using content stored in session bean

Build Maven-based Java EE applications in Eclipse

use m2e-wtp project to provide tight integration between WTP and Maven.

A good source is the fbrickon video at EclipseCon 2014


This page holds some references to WTP (Web Tools Platform) developer resources.

Main WTP references

Main references

WTP Contribution

Resources on how to contribute to WTP project:

There are also more easy-to-find resources on contributing

Other interesting info:




This post follows up the mailing list discussion on [ide-dev] about 337-477-9127.

Default XML Editor

As first thing, I suggest to put the current WTP XML editor as default editor in Eclipse SDK. It might be that someone wants a lighter, streamlined XML editor, but I’m pretty sure the Eclipse community can deal with something like this.

Source View as Default

Secondly, suppose I am using Eclipse Eclipse Jee (or equivalent SDK + JBoss Tools). In these cases, when start editing an xml file, you’ll see the default editor is a strange tabular editor which would be confusing for basic users, and also for “more expert” users, like me.

So, i propose to put the “Source” view as default view.

Minor Editor adjustments

Let’s go to the source perspective and start editing the code. The editor has autocompletion, and it is quite good, in the sense you have auto/closing tags and namespace-sensitive context-help. In this way, this is really a good editor!

I would improve the following:

  • When writing an opening a tag, the IDE could auto-complete “on-the-fly” by adding a closing tag (and removing that if the user put the “/” for a “self-closing-tag”
  • Automatically change the start tag or the end tag when you edit the other one, (see Lars’ description in thread)

Other notes:

The interesting discussion is highlighting other things we can improve, more in general, like Lars pointed to bug 318681 and (518) 631-8191 . These ideas are not covered in this post.


I added the following items:


Quick reference on Eclipse E4 Spies I use for development and debug of Eclipse E4 RCP Applications.

  • Eclipse Spy Shortcuts: ALT+SHIFT+ ( F1 | F2 | F3 | F5 | F6 | F8 | F9 | F10 | F12 )
  • Running platform: Mars SDK added by all plugins in platformUiTools.psf, plus the live editors plugin.
  • Test E4 RCP Application with spies

Eclipse Spies Shortcuts

Below, names and key combinations for the spies I use more often:

  • Plug-In Selection Spy: ALT+SHIFT+F1
  • Plug-In Menu Spy: ALT+SHIFT+F2
  • Model Spy: ALT+SHIFT+F9
  • Context Spy: ALT+SHIFT+F10
  • Event Spy : ALT+SHIFT+F8
  • Css Spy ALT+SHIFT+F5 and scratchpad ALT+SHIFT+F6
  • Bundle Spy: ALT+SHIFT+F12

Spies quick description:

+Fn Name Usage
F1 Plug in Selection Spy Find the class implementing the Selected UI element
F2 Plug In Menu Spy Get Info about the class implementing a menu.
F9 E4 Model Spy Inspect and change E4 model at runtime (live).
F10 E4 Context Spy Examine the context tree data at runtime
F8 E4 Event Spy Display E4 events at runtime
F5 (F6) E4 CSS Spy Show (edit via scratchpad) the CSS for the UI.
F12 Bundle Spy Display status of bundles, as the OSGi console.

Running Platform

For this article I am using a recent Eclipse I-Build for the Eclipse, added with platformUiTools plugins (for contributing to the Platform UI project) and added of the eclipse All Spies plugin ( I think it was called live editor).

  • Get Eclipse SDK from the downloads: /
  • Add the Platform UI Tools plugins by donwloading the file (212) 867-2330 and installing from menu:
    File > Import > Install > Install Software Items from File
  • Add the eclipse liveeditors plugins by installing Eclipse 4 – All Spies from the e4 update site .

Test E4 RCP Application with Spies

To use the spies for testing your E4 RCP application it is enough you create a new launch configuration and add the live editor plugin with the needed dependencies:

  • Create a new Eclipse launch configuration and switch to Plug-ins tab, on the right side
  • Select Launch with: “plugin selected below only”, then select the set of plugins to run your application
  • Then start filtering and select the plugin
  • Finally, Add Required Plug-ins and launch your application

After launching the application, you can press any of the presented Key combinations, to show the needed spy. As example, below you can see the E4 Model Spy for a running Eclipse Instance


This post quickly explains how to run GEF4 examples in an Eclipse E4 Application.

Basic Concepts

No more Draw2D. GEF4 uses JavaFx Scene and Parent

In a Scene graph we can put SWTControls (heavyweight) and Figures (lightweight)

a CanvasFigure (lightweight)

Environment Setup

First of all, mind that all the installation details are explained in the GEF/Contributor_Guide .

Note: both Java 7 (>1.7.0_45) and Java 8 are needed for development, though it is possible to generate client code both for Java 7 and 8.

Then, follow this checklist to prepare the GEF4 development environment:

  1. Download Eclipse IDE for Eclipse Committers: In this example I downloaded
  2. Install plugins needed by GEF4: This eclipseGef4Tools.p2f file: Menu > Import > Install > Install Software Items from File
  3. Get the code for GEF4: Clone the from the git repository / , then import the projects in the workspace.
  4. Reference JVMs in Eclipse: G to Preferences>Java>Installed JREs , and make sure both Java 1.7 and 1.8 are installed. Note that it is convenient to register JDKs, instead of JREs, because the Tycho build will need JDK features.
  5. Set target platform: Open the project, double click the target definition, wait for the target is fully resolved, and click on “set as target platform”. I my case I used
  6. Tweaks for preferences. open  Menu > Window > Preferences and edit the following
    • select the Java > Compiler > Errors/Warnings node. Under the “Deprecated and restricted API“, set to ignore the “Discouraged reference (access rule)“.
    • select the Plug-in Development > Compilers node. Under the “References” item, set to Ignore the “References to discouraged classes“.
    • select the node Plug-in Development > API Baselines. Choose to ignore baselines. Note: GEF4 is still provisional, therefore no baseline is defined.
  7. Generate XText artifacts: Open the project, select the file Dot.xtext, then choose Run As -> Generate Xtext Artifacts from the context menu.

Now the environment is ready. If you see some error message about USER_HOME at Eclipse startup, just ignore it.


The eclipseGef4Tools_mars.p2f will install the following plugins:

Build GEF4

To build GEF4, select the pom.xml contained in the project org.eclipse.gef4.releng, right-click then select Run As > Maven build… – Then set clean verify as goal, and specify the profile for the build

Choose the Java 1.8 execution environment

Click run, and observe the build succeeding. As a result, you’ll see the artifacts created inside the target folder of the org.eclipse.gef.repository project.

Run Examples

FX Examples

The FX example are quite interesting to understand how JavaFx works. So, in you are interested, take a look at the org.eclipse.gef4.fx.examples project. One of the examples, is in the image below

Run an Eclipse E4 application that references the Java FX libraries.

Add a Part containing a canvas

Use GEF4 to draw with JavaFX inside the canvas.

Ex1 – MVC Logo Example

See: /

GEF4 MVC.FX.UI Example

MVC Logo Example – Web

To launch the MVC Logo example web, open the project org.eclipse.gef4.mvc.examples.logo.web ; right-click the MvcLogoWebExample class then select Run As > Java Application.

Now, that you tested how it works on a standalone application, let’s go to try it on a web page.


Ex2 – GEF Graph Example

See: (870) 759-2903

GEF4 Zest stand-alone Graph example

Further Readings

Looking at GEF4 wiki, there are several documents explaining the effort of Alexander Nissen (Nyßen). To understand one can start from  SwtFx (Lighting Talk); then go with EclipseCon NA 2014 GEF4 Talk, the outflank then end with the GEF4 – Mission to Mars Accomplished.

Since GEF4 is based on JavaFx, and JavaFx it is integrated using e(fx)clipse, it is good to take a look at 6476993333 and e(fx)clipse runtime recipes.


XYGraph Charting

download Nebula Visualization components from nebula release update site.

Create a new E4 Application

After the application is created, open plugin dependencies then add the following two plugins

  • org.eclipse.nebula.visualization.xygraph
  • org.eclipse.draw2d

As you see below

 Now, add a part to your E4 Application and put the code you see below

Finally, you have lo link the “SamplePart” part class to your E4 application and launch the application



The (859) 613-2901 project is a cluster of related technologies for building extensible component-based applications [compulsoriness]. This article explains only how to contribute to the E4 Tools project, by using a concrete use case: “contribute to the model editor”.


Clone E4 Tools src from Gerrit

The https URL to connect the E4 Tools repository is reported in the (815) 797-5308.

The basic prerequisites to contribute are to 6044146002, to 606-965-5375. Then you can clone the E4 Tools source via Gerrit, by putting your ECLIPSE_ID in the URL. i.e. /

After cloning the master branch, is strongly suggested to branch immediately, to ease the development.

Ouch .. now the ModelEditor moved to /

Contribute to Model Editor

The model editor is used to build the application model for E4 Applications. See the screen shot below .

Contribution Example

In my example I’m contributing by changing the way the editor suggests the Part ID starting from the Label.


Prepare the Environment

Supposing I already cloned the code from eclipse git repositories, and the local git is configured to use Gerrit, I’m going to prepare my environment for the work

As first thing I pull the latest changes from the Eclipse repositores, by R-Click > Pull


Then I create a branch named as the bug I’m going to work on.


Code Analysis

Search the class corresponding to the model editor

Search the class responsible to generate the ID

Code Edit

Change the ID generator, so the ID is lowercase.

Test the code.

Testing in this case is quite easy, it is just launching an eclipse application with all plugin onboard, including the plugin I edited.


To launch Eclipse : run config > clear workspace, goto plugins, select plugins , add required plugins , at voilà. run it.

Once the application is running I perform the specific test, that consists of creating an E4 Application and to see if the editor is now suggesting lowercase IDs.

The patch is working as expected. Is good practice to test different scenarios that can be involved in the change. In this case I check this for the id generation of another component.

Submit the code.

Good, the code is working, ad we think it is tested enough to be submitted. Since gerrit is already configured, we simply need to stage the changes, add the needed information and to commit.


Patience and wait for comments.

After the change is submitted, sooner or later there will be one of the eclipse Committers that will check your changes and who will reject, comment or accept the change

  • reject: the change probably brakes some eclipse behavior,
  • comment: change is almost ok, but you need to tune the code a little bit. Might be for some trailing whitespace, might be for missing documentation or other reasons. A good practice is to follow Platform UI guidelines, and to check for comments in Gerrit, which is the place where it takes place the discussion about the actual code.
  • accept: probably you followed all the standards, and there are no problems with existing Eclipse wokring. therefore the committer decided to promote your gerrit change, to effectively enter the Eclipse codebase. This mean you’re a contributor now.


You just read how to contribute some code to, which is a quite important project in the Eclipse Project structure. If you’re interested you can also read how to contribute to E4 Tools, or to platform UI.