Orion Moved to Github

You may have heard a couple of weeks back that Orion moved to Github. If not, then let this be the notice that Orion moved to Github!

We are very excited about the move. The webmasters (Derek Toolan in particular) did an amazing job in making the transition seamless and simple.


You are probably wondering to yourself: “why did you move, you had a great home at eclipse.org?”. The answer boils down to simpler contributing. With Github, we felt that it would be far easier for committers, community and everyone in-between to be able to contribute to our project. No more Gerrit, confusing Gerrit configurations, or multiple remotes – just fork the project, make awesome code and open a pull request. Simple.

Ok, so where’s the code

All of the Orion source code can now be found in the following locations:

  • orion.client – the Orion client code
  • orion.server – the Orion Java server code
  • orion.server.node – this will eventually be the home of the Node.js-based Orion server. Its currently empty while we sort out what code we want to separate out
  • orion.electron – this will eventually be the place we host our Electron-based app from. Currently it is empty while we sort out the builds, etc for the app

What else do I need to know?

There are a few pretty important things that need to be addressed – especially if you are currently a contributor / committer to Orion.

  1. Make sure your Eclipse account is linked to your Github id. This is super-mega-ultra important, especially if you are a committer. The webmasters have provided a great wiki page that talks more about this.
  2. Make sure to update your repos / remotes. The old Git repositories have been set to read-only (as have the gerrits) – so make sure you update (or just re-clone) the repositories to avoid accidentally working against the old stuff.
  3. We are still using Bugzilla (so no changes in how to file / search / triage bugs). For the time being we will keep using it until we figure out a good flow for tracking issues across multiple repositories in GitHub.
  4. All contributions should be made as pull requests. The Gerrit instances for each old repository are set to read-only so they cannot be used, and if you really want to, you could still attach a patch to the bug you want to fix (but seriously, please use a pull request).

Thanks again to everyone that helped make this possible.

Happy coding!

Posted in Announcements, New & Noteworthy | 1 Comment

Orion 14.0 New and Noteworthy

Another three months and another awesome release! Its that time again where I share all of the cool new features, enhancements and fixes with you. As usual with every release, there were lots of changes, so lets jump right in.


The work that began in 13.0 to make Orion completely accessible to every developer continued at a furious pace in 14. This time around, our work was focussed on having the correct colour contrast.

We tightened up our colours in the light theme so that all colours pass the WCAG 2.0 AA guideline for colour contrast. The changes are subtle, but they do make text easier to read, as seen in this before-and-after snapshot of selected code in the editor.

Selected text comparison

Comparing selected text in 14.0 vs. 13.0

Language Tools

Automatic Project Configuration

The JavaScript tooling can now read and understand complex project configurations and automatically configure Tern for the best development experience. For example, the tools can better read and understand package.json files and automatically load available plugins into Tern (rather than the user having to tailor their configuration settings).

Projects Anywhere

Using the new support from the platform to find project contexts, the JavaScript tools can now support a “project” at any level in the navigator. Where a project means any folder that contains JavaScript project-like files – package.json, .tern-project, etc.

Smarter Defaults

The default configuration for the JavaScript tools has been retooled to provide more support right out of the box. In Orion 13.0 (and before), we started the tools in a very bare-bone fashion, and would alert you about potential configuration changes (with quick fixes). Now we automatically start with ECMA, node and browser support, and configure your project as you code.

Disable Linting In-File

Tired of being nagged about a particular code pattern used in certain places (but like to be warned elsewhere)? You can now use the new quickfix to ignore the problem in the current file.

Disable rule in-file

Disable rule in-file

JavaScript Type Icons

In an effort to make the overload of information (while coding in JavaScript) a bit more understandable, we have added icons to help users immediately understand the type of something. For example, F stands for function, O is for objects, C is for classes, etc.

Type icons

Type icons

Improved ESLint configuration file support

We have improved how the JavaScript tools handle the various forms of ESLint configuration files. We now properly support all entries of the files (except for extends).

SVG Support

The CSS and HTML parsers have been updated to properly support SVG attributes and properties. The HTML and CSS validation has also been updated to properly process the new attributes and properties.

Platform Improvements

Syntax Styling

Syntax styling grammars can now define a firstLineMatch attribute.  This enables multiple grammars to be defined for a content type, and the grammar that gets applied will be chosen based on the first line of content.


The node server now stores its tasks metadata in a Mongo DB when running as multi-tenant.  As a result, requests querying long-running tasks can now be handled by different server instances that have access to the shared Mongo DB.

Automatic Syntax Checking

Previously, syntax checking took place when a file is saved – if you have autosave turned on in Orion, this is not a problem, as problem markers would be updated as you made changes. If however, you had autosave turned off, any problem markers would quickly become stale causing confusion. Now, in Orion 14, syntax checking will take place on a regular interval even if autosave is turned off, to try and avoid stale problem markers piling up.

New File Client API

The Orion file client has been updated with the ability to find a project given a particular resource path. The new API can be invoked as:

fileClient.getProject(resourcePath, options)

Information Annotations

A new type of annotation has been added to Orion – the info annotation.

The info annotation

The “info” annotation

Annotation Visibility

Always wanted to only show annotations in certain parts of the IDE? Well, now you can.

Simply navigate to the editor settings preference page, and look for the Annotations, Overview Annotations and Text Annotations sections to configure annotation visibility as you’d like.

Annotation visibilities

Annotation visibilities

Don’t forget, you can also use the handy star buttons to have the preference(s) show up in the quick preference menu.

IDE Themes

Finally, after all this time, we have the ability to change the theme of not just the editor, but the entire IDE from the preferences!

Not happy with the default theme in Orion? Head over to the IDE Theme preferences page to change to another theme (currently there are only two of them) or create your own (by modifying an existing theme and saving it as your own).

IDE Theme preferences

IDE Theme preferences

Posted in New & Noteworthy | Tagged , , , , | Comments Off on Orion 14.0 New and Noteworthy

Announcing Orion 14

We are pleased to announce the fourteenth release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thank you to all committers and contributors for your hard work this release.  There were 150 bugs and enhancements fixed, across more than 380 commits from 14 authors!

What’s new in Orion 14?  This release was focussed on quality and ease of use – Orion 14 is more accessible (better colours and accessibility), easier to start coding in (the tools now automatically understand complex project configurations, so you don’t have to), and just more awesome in general.

We continued to improve the Node.js server (which is used on orion.eclipse.org or locally), and continued to improve our Electron app. Lastly, we began work in 14.0 to provide collaborative development support and debugging support directly in Orion! Stay tuned in Orion 15 for these features to officially land.


Posted in Announcements | Tagged , , , | 2 Comments

New and Noteworthy in Orion 13.0

With Orion 13.0 released (just in time for the holidays), it is time again to share with you the new & noteworthy items developed during this release. There are lots of changes across all of Orion, so lets dive in to each area and see whats new.


We have been striving to make Orion as accessible as possible to all developers. In Orion 13.0 we have improved accessibility across the board – from standard labels to the code edit widget and everything in-between. We still have a ways to go, but plan to be fully accessible in Orion 14.0.

Code Edit Widget

The code edit widget just keeps getting better and better. In Orion 13.0 two great things happened: (1) You can finally see the keybinding dialog, and, (2) you can now add your own custom code folding!

To jump right in and start enhancing your use of the widget with some cool folding, check out the docs.


We have created an experimental version of Orion that runs as an Electron app!

The Experimental Orion Electron app

The experimental Orion Electron app

Currently, to use the app, you have to build and run it locally (we are working on providing regular builds of the app).

Language Server Protocol

A lot of work has gone into investigating and supporting the language server protocol since its announcement last summer.

In Orion 13.0 we have experimental support for the LSP and for Java that can be used on your local machine. For full details on how to get up and running, see this great readme.

Language Tools

Lots of cool new stuff is available in the language tools in 13.0.


We have provided 13 new linting rules (a coincidence, I promise), such as, no-extra-bind and no-implicit-coercion. The complete list of rules added in 13.0 can be found on our rules wiki.

The no-implicit-coercion linting rule

no-implicit-coercion (with fix)

To accompany the new linting rules, many new quickfixes have been added as well, allowing problems to be quickly and easily resolved.

The quotes linting rule quickfix

quotes rule quickfix

To keep all of the rules running smoothly, we also updated to ESLint 3.0.1

ECMA 2016

Orion 13.0 ships with complete support for ECMA 2016. To start developing using the new language features, you have to make sure to set the ecmaVersion entry in your .tern-project file to 7.

ECMA 2016 example snippet showing content assist

ECMA 2016 example

AST Outline

A lot of times, while working on language tooling features, developer have wondered what the backing AST looks like (to help diagnose whats wrong). In Orion 13.0 we have provided an AST outline for JavaScript, to make this task easier.

You can see the new outline using the View > Slideout > AST Outline menu item when working in JavaScript files.

The AST outline showing a simple snippet

AST outline

Code Formatting

One of the most sought-after features of an IDE is the ability to quickly fix the shape of code. One of the easiest ways to do that is code formatting. In Orion 13.0 we provided a platform API (orion.edit.format) to add formatting to any language, editor hooks to format-on-save, support to format selections of code and support for .jsbeautifyrc files (for project-level formatting options).

Orion ships with four language formatting implementations: (1) JavaScript, (2) HTML, (3) CSS, and (4) JSON.

Formatting can be used in one of three ways:

  1. Format-on-save: head into the editor options to enable this feature, then, as you save your work, it will also be formatted
  2. The Edit menu item: look for Format Code under the Edit main menu
  3. The pop-up menu: look for Format Code in the pop-up menu in the editor
Format code popup menu from the editor

Format code in editor

Not happy with the way the formatted code looks for JS/HTML/CSS/JSON? Simply head over to the formatting preference pages for each language and change the settings as desired.

The page with CSS formatting options on it

CSS formatting options

HTML Validator

In addition to updating our HTML parser in Orion 13.0, we also provided a pluggable HTML validator to help you keep your page source in tip top shape.

Example HTML validation

HTML validation

Like all our other validation, you can configure the HTML rules severities. The settings are found on the HTML Validation settings page.

Improved Internationalisation

All of the linting messages coming from the CSS tooling can now appear in other languages than English.

Updated Libraries

As we do each release, we have updated many of the libraries we use in our language tools. This time around we updated the following:

  • ESLint to 3.0.1
  • Doctrine to 1.2.2
  • ESTraverse to 4.2.0
  • Acorn to 3.3.0

Platform Improvements

Syntax Styling

Orion 13.0 has improved syntax styling support for many of our existing languages (like PHP and SQL) and also adds support for .sh files

Excluded Files

Any callers of the search API (via the file client) can now specify an array of names to be ignored by the search engine. This allows callers to ignore all kinds of things they don’t care about while speeding up the search for things they do.

The new property is named ‘exclude’ and is an array of strings. See the API doc for more information.

Filtered Resources

Sometimes there are things you just don’t want to see in your workspace (or that you shouldn’t see). In Orion 13.0 we provided the ability to filter / hide resources from appearing in the UI.

The preference for this is on the General settings preference page and is a simple comma-separated list of names of things to not show.

Shows general settings page and hidden resources preference

Resource names to hide

Light Theme

Orion now sports a shiny new light theme!

But don’t worry if you really really liked the old theme, in Orion 14 we are bringing back the theme preferences to allow this to be customized.

Posted in New & Noteworthy | Tagged , , , | Comments Off on New and Noteworthy in Orion 13.0

Announcing Orion 13

We are pleased to announce the thirteenth release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thank you to all committers and contributors for your hard work this release.  There were over 180 bugs and enhancements fixed, across more than 350 commits from 13 authors!

What’s new in Orion 13?  The Orion 13 release continues to emphasize our language tooling.  In particular, we now have code formatting, support for .jsbeautifyrc files and full ECMA 2016 support.  We have also been investigating LSP and have some experimental work in place to support Java, but this is not yet generally available.

The other focus of this release is consumability and accessibility. To make Orion easier to use for end users, admins and everyone in between, we substantially improved the node.js server (which is used on orion.eclipse.org or locally), created an experimental Electron app version of Orion, improved accessibility, enabled custom code folding in the code edit widget and a whole lot more!


Posted in Announcements | Tagged , , | 2 Comments

Google Cloud Shell adopts the Orion Code Editor

It’s nice to see Google Cloud Shell using Orion in their latest offering. Google Cloud Shell is just that: a shell (really a bunch of shells) to a machine in the cloud. The machine contains source files (go figure) and Orion is great at editing files, syntax coloring, code assist, refactoring, dynamic linting and much more.

This is how you get to Orion in Cloud Shell:


Here is Orion running in Google Platform Shell:


I am reminded that IBM makes extensive use of Orion as a code editor in Bluemix DevOps Services and that we should really blog about that again soon.  Development in the cloud for the cloud!


Posted in General | Comments Off on Google Cloud Shell adopts the Orion Code Editor

New and noteworthy for codeEdit widget 12

Orion codeEdit widget debuted just one year ago in Orion 9.0. Thanks to all the valuable user feedback over the past year, now in Orion 12, the widget has been improved a lot for both usability and customizability. We’ve updated the widget wiki page to include the latest features, summarizing user feedback in the FAQ section.

The codeEdit demo page shows you two of the biggest improvements in the widget: customizable editor configurations and fine tuning your web language tooling. In Orion 11.0 we introduced tern project – now this feature is integrated into the widget. In the demo you will see a zoom ruler in each editor, enabled by an editor configuration change. You will also see how the javascript file validation behavior changes while live editing the tern project and eslint rule files.

Aside from that, there are other major improvements that are not shown in the demo.

With all the improvements so far, we found it’s been much easier for the existing users to consume and customize the widget. We are still improving in other areas so please stay tuned.

Posted in General | 1 Comment

New and Noteworthy in Javascript tooling for Orion 12.0

As noted in our Orion 12.0 announcement, a tonne of work has gone into this release of Orion.  Over 350 Bugzilla reports were fixed.  Here are some of the many things we have been working on for the JavaScript language tooling.  Expect more in-depth looks at these items in the next few weeks.

Cross-file linting

The ESLint based validation in our JavaScript tools up to Orion 11 was only focused on the single file you were editing.  No consideration was given to the rest of your project setup.  With 12.0 the linting is now aware of the other files in your workspace and the project configuration you have set up.

  • no-undef: Warn when a global variable has not been defined
  • no-undef-expression:  Warn when a function (member expression) has not been defined
  • no-unused-vars: Warn when declared variables are not used.
  • unknown-require:  Unknown required library
  • type-checked-consistent-return: Discouraged inconsistent returns

So we can now in many cases tell you that you are using a function that doesn’t exist.  Especially helpful when you mistype the name or use the wrong casing.

Make the tools consumable

We have created a new API and webpack build that will package up the JavaScript tooling in one consumable bundle that can be used to drive language plugins for other IDEs, such as Brackets or Atom.

A deep-dive into the new API is coming in a subsequent blog post. To get a jump on it, we have provided two wiki pages: (1) JavaScript tools API and, (2) Building the JavaScript API.

Improved Tern integration

In Orion 12.0 we moved the remainder of our client-side services to be Tern plugins.

These new plugins include:

  1. ESlint
  2. Occurrences
  3. Templates / templating
  4. Quickfixes
  5. Outlining

The move to be more Tern-centric with our features carries many benefits, but most importantly it allows us to cut down on message passing, improve memory use and make the features more portable.

ECMA 2015 support

Orion 12.0 supports all of the ECMA 2015 specification like arrow functions, import/export statements and classes.

The tooling completely understands the new language syntax with new quick fixes and code templates also being available to get you started.  The linting rules have also been updated to respect the new ECMA 2015 code patterns.

Outlining has been updated:

ECMA 2015 outlining support

ECMA 2015 outlining support

Occurrences has been updated:

ECMA 2015 occurrences support

ECMA 2015 occurrences support

Linting has been updated:

Lint rules updated for ECMA 2015

Lint rules updated for ECMA 2015

We also support import and export statements which require the source type to be “module”. This is set through the .tern-project file – and you can use a handy quickfix to write it all for you.

Change sourceType quickfix

Change sourceType quickfix

Support for ESLint project configuration files

Users can now include .eslintrc files in their projects.  These files can configure all of the ESLint settings that your files are validated with, including rule severities.

.eslintrc file example

.eslintrc file example

When this file is present, the rule values will override any workspace settings.  If you go from editing your project to changing settings the page will warn you that an .eslintrc file is present.

Preference warning banner for .eslintrc overrides

Preference warning banner for .eslintrc overrides

We support other forms of ESLint configuration too, such as settings in package.json. There is a hierarchy of configuration files that you can use. Read the full details on ESLint’s configuration page.

Package.json ESlint configuration section

Package.json ESlint configuration section

Support for in-project definition files

You can define and use your own definition files in your project. See the file IndexCreation.md to find out how to proceed.

Tern index file example

Tern index file example

The tooling will include all the type information found in your definitions to improve content assist, tooltip hovers and more.

Content assist for example in-project index file

Content assist for example in-project index file

Updated third-party libraries

Most of our third-party libraries have been refreshed:

  • Acorn 3.1.0
  • Doctrine 1.2.1
  • ESrecurse 4.1.0
  • Estraverse 4.1.1
  • Escope 4.2.0
  • Tern 0.18.0

A notable change to our consumed library lineup is that we have discontinued use of the Esprima parser in favour of Acorn.  There are many reasons for the switch, but the main reasons are:

  • Acorn has complete ECMA 2015 support (with recovery for most of it).
  • We can easily extend the Acorn parser via its plugin mechanism, so there is no need to edit parser code to have our Orion customizations.
  • Acorn has robust recovery support right out of the box (no more editing the parser to hack our own in).
Posted in New & Noteworthy | Tagged , , , , | 1 Comment

Announcing Orion 12

We are pleased to announce the twelfth release of Orion, “Your IDE in the Cloud”. You can run it now on OrionHub or download the server to run your own instance. Once again, thank you to all committers and contributors for your hard work this release.  There were over 350 bugs and enhancements fixed, across more than 900 commits from 22 authors!

What’s new in Orion 12?  The Orion 12 release continues to emphasize our JavaScript tooling.  In particular, we now have full support for the ECMA 2015 spec, vastly improved project configuration capabilities, support for eslintrc.* files and much much more!

The other focus of this release is consumability. To make Orion easier to use for end users, admins and everyone in between, we created an experimental node.js server (which can be used on orion.eclipse.org or locally), a metrics service for plugins, some super cool updates to the code edit widget and a whole lot more!


Posted in Announcements | Tagged , , | 1 Comment

Configuring your Orion project

Everyone loves to customize stuff.

In Orion 11.0, we provided support for .tern-project files so you can do just that. A .tern-project file, for those unfamiliar with them, is a configuration file that lives at the root of your project, is entirely JSON, and tells Tern how and what to run with.

Lets see an example file (the one used in the Orion client):

  "plugins": {
    "node": {},
    "requirejs": {},
    "express": {}
  "ecmaVersion": 5,
  "libs": [

See? It’s not so bad. Now lets talk about what all the parts mean, and why you would want to make one.

The first thing typically asked when talking about these files and configuring your project is: “what if I don’t have a .tern-project file?”. The short answer is; we start Tern with a default configuration that contains every plugin we pre-package in Orion.

The longer answer is:

  1. you get all of the required core services plugins from Orion (like HTML support, parsing plugins, etc)
  2. you get all of the pre-packaged plugins (mongodb, redis, mysql, express, amqp, postgres, node, requirejs and angular)
  3. you get a default ECMA parse level of 6
  4. you get a default set of definitions (ecma5, ecma6, browser and chai)

Basically, everything will work right out of the box, the downside is that you get a lot more stuff loaded in Tern than you might need (or want).


This is the most common element that people create a .tern-project file for, and its an easy one. If you are coding against ECMA 6, the defaults are fine. If you are not, its best to change this to be 5.


This entry describes type libraries you want Tern to use. These libraries provide type information that is used for content assist and inferencing. At the moment, only the definitions that come pre-packaged in Orion can be entered in this list, which include  ecma5, ecma6, browser and chai.

I know what you are thinking. What if I have a definition not in the list I would like to use? We are working on support for custom definition files directly in the project, and providing a UI to install new ones.


This entry describes all of the plugins that you want Tern to run with. As mentioned, by default you get everything. Leave it out? You get everything. Empty plugins entry? You get everything.

Regardless of what you put in the plugins entry, you will always get the core services plugins that Orion needs to function – so no, you cannot break the tools.

While everything will work fine right out of the box with all plugins running – you can really improve the performance and memory usage of the tools if you tell us what support you actually need. For example, working on a node.js project? only include the node plugin. Working on AMD browser project? only include the requirejs plugin. You get the idea – only load what you actually need.

At the moment, the list of plugins that can be enabled is amqp, angular, express, mongodb, mysql, node, postgres, redis, requirejs. And yes, we are working on ways to provide your own.


This entry is a list of files that are so important, that you just have to have Tern load them when it starts up. All joking aside, this entry is best for pointing Tern at the ‘main’ in your project. For example, say you were working on a web page. You could add index.html in the loadEagerly entry to have Tern automatically load that file and all the dependent scripts right away, so everything was primed and ready to go immediately (as opposed to Tern filling in its type information as you open and close files).


Don’t change this entry. Set too low, it will cause dependency resolution to time out (incomplete type information). Set too high, the IDE will wait longer before answering whatever you asked it (content assist, open decl, etc).

So thats it. Those are all of the supported entries that can appear in the .tern-project file. A pretty short list.

You can’t break the tools by setting a bad entry – we have sanity checking that will revert to a “something is wrong, load the defaults” state. We also have linting / sanity checking that will alert you if you have broken something in the file.

Tern project file linting

Tern project file linting

Broke the file and still navigated to another file (or maybe brought in a change from git that broke the file)? We will alert you that its bad in the banner, with a handy link to jump to the file and fix it!

Tern project file banner message

Tern project file banner message

Remember, you can ignore all the warnings (if you really want to) and Tern will still start with the defaults as a safety measure.

Feeling a bit lazy and don’t want to type out a brand new file for your project? Just open up the new (empty) .tern-project and hit Ctrl+Space, which will auto-magically insert a shiny new template for you.

Happy configuring!

Posted in General | Tagged , , , | Comments Off on Configuring your Orion project