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 JSDT bugzilla. [486037477020]

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 page.


  • eclipse.platform.runtime : [gerritBrowse repo] source repo required for quitting some IDE validation at compile-time.
  • webtools : [Browse repo] contains the website for all the webtools project. It’s big, needed to update project page
  • webtools.jsdt : [gerrit,Browse repo, 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: [gerritBrowse 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 jsdt_2010.psf, 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 my previous article.
  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 webtools.jsdt/developer (and platform.ui/developer) 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 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: jsdtSimpleProjectSet.psf .

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.


This post follows up the mailing list discussion on [ide-dev] about Ctr-1driven development in Eclipse.

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 bug 35000 . These ideas are not covered in this post.


I added the following items: