License Certification (Mostly) Just Happens

by waynebeaton at July 19, 2017 05:17 PM

The Eclipse Intellectual Property Policy defines two types of intellectual property (IP) due diligence for third party content. The so-called Type A Due Diligence is concerned exclusively with license certification; and Type B Due Diligence is concerned with license certification, provenance checking and a deep dive scan of the content for various anomalies.

Regarding the analysis of Type A third party content, the IP Policy makes this statement:

It will be the responsibility of the Eclipse Project to run and analyze the results of a scan tool provided by the EMO, using parameters provided by the EMO, to obtain the terms and conditions under which such Content would be distributed by the Eclipse Foundation, and ensure that such terms are consistent with the Project Licenses. The Eclipse Project will certify that the terms and conditions of its Non-Eclipse Content conform to the then-current licensing guidelines as provided by the EMO. No further approvals will be required from the EMO prior to the Eclipse Project placing the Non-Eclipse Content into the Repository.

In short, it is the project team’s responsibility to run a tool, analyse the results, and certify the content as being consistent with the various conditions. It took us a while to identify the scan tool.

The Eclipse IP Team has been using open source Fossology for a while. While Fossology is a very comprehensive tool that’s great for IP Analysts, our experience suggests that the learning curve is too steep for it to be used by committers. What we wanted to provide was a tool that could generate a simple report (both human and machine readable) containing a manifest and corresponding licensing.

We found what we needed in ScanCode, which is produced by some old friends at NexB. ScanCode has the ability to generate the manifest and summarize findings in a number of different formats, including HTML, JSON, and SPDX RDF and Tag/Value. Using ScanCode is pretty easy. In fact, it’s so easy that the Webmaster integrated its use into an Eclipse Genie script. So… for a project team to run the tool, all they really need to do is create a CQ. The rest just happens automatically.


In cases where the third party content has a single white listed license, committers only need to create the CQ and then add the content to their builds. If Eclipse IP Team review is required, the committer may need to participate in that review.

To leverage this automatic scan, a project committer creates a Type A contribution questionnaire (CQ) in the usual way and attaches the corresponding source code. The magic happens after the PMC gives their approval: the Eclipse Genie process identifies every Type A third party content CQs that has been approved by the PMC, runs ScanCode on the source code attachments, and then attaches the report directly to the CQ.

If a single license is identified for all files in the third party content, and that license is on our white list (see below), then the CQ is automatically marked license_certified, its license information is updated, and the CQ is marked resolved. If multiple licenses, blacklisted licenses, or otherwise problematic licenses are detected (i.e. anything other a single white listed license), then the CQ is sent to the Eclipse IP Team for further investigation.

When you see something like the following on your CQ, you’re good-to-go.

Screenshot from 2017-07-18 15-19-46

At this point, the content can be used in project builds and included in milestone builds. Once all project CQs are either marked as license_certified (type A) or approved (type B), the project can do an official release.

I’m really curious to see what sort of hit rate we get on automatic license certification, vs. how many requests will have to be reviewed by the Eclipse IP Team. My hope is that we will get to a point where we have an 80% automatic approval rate; but we don’t have enough data to make a call yet.

Our current implementation has the following licenses in the white list:

  • Apache License 2.0
  • Apache License 1.0
  • Apache License 1.1
  • BSD 2 Clause
  • BSD 3 Clause
  • BSD 4 Clause
  • Eclipse Public License 1.0
  • Eclipse Distribution License 1.0
  • MIT License
  • ISC License
  • NTP License
  • OpenSSL License
  • Public Domain
  • W3C Software and Notice License
  • zlib license

We need to find a home for this. This list will grow.

We’re using Bug 496959 to track our work to update our processes and documentation regarding the Eclipse IP Process.

by waynebeaton at July 19, 2017 05:17 PM

JBoss Tools 4.5.0.AM2 for Eclipse Oxygen.0

by jeffmaury at July 19, 2017 11:01 AM

Happy to announce 4.5.0.AM2 (Developer Milestone 2) build for Eclipse Oxygen.0.

Downloads available at JBoss Tools 4.5.0 AM2.

What is New?

Full info is at this page. Some highlights are below.

OpenShift 3

OpenShift server and Kubernetes server versions displayed

The OpenShift server and Kubernetes server versions are now displayed in the OpenShift connection properties. This information is retrieved using an un-authenticated request login to the OpenShift cluster is not required. This allow user to verify the OpenShift and Kubernetes level when interacting.

Here is an example based on an OpenShift connection against CDK3:

openshift k8s versions

if the cluster is not started or accessible, then no values are displayed:

openshift k8s versions1


New Security Options

Support has been added when launching commands in a Container to specify a security option profile. This can be done in lieu of specifying privileged mode. For example, to run gdbserver, one can specify "seccomp:unprofiled" to allow ptrace commands to be run by the gdb server.

The Run Image Wizard has been modified to allow specifying an unconfined seccomp profile to replace the default seccomp profile.


Security options are also now shown in the Properties View.


Fuse Tooling

Bean Support

We are happy to finally announce support for Beans (Spring / Blueprint).

Using the Route Editor you can now access Spring / Blueprint Beans in your Camel Context through the Configurations tab.

Configurations tab in Editor

In the Configurations tab you can see all global configuration elements of your Camel Context. You can Add, Edit and Delete elements using the buttons on the right side.

Configurations tab content

By clicking the Add or Edit button a wizard will be openend to guide you on the creation of the Bean.

New Bean wizard

In the wizard you can select an existing bean class from your project or create a new bean class. You can also specify constructor arguments and bean properties. Once created you can then modify the properties of that Bean inside the Properties view.



Freemarker component deprecation

The Freemarker component has been marked deprecated as there is no more maintenance on the source code. It is still available in Red Hat Central and may be removed in the future.


Jeff Maury

by jeffmaury at July 19, 2017 11:01 AM

Eclipse Hackathon Hamburg – July 2017

by Philip Wenig at July 18, 2017 08:24 AM

We tried an experiment yesterday, it was quite successful. Instead of having just a meeting in the evening, we started at 11 am … eventually, it also lasts till the night :-).

Over the day, we’ve been approx. 20 people. Definitively, we will do it again! Also a big thank to the University of Hamburg and Prof. Dr. Walid Maalej who hosted us:

And a big thanks to the Eclipse Foundations for Pizza and Beverages!

In summary, 25 bugs have been fixed:


I worked on many improvements of the SWTChart extensions as part of the Eclipse Advanced Visualization Project:



See you at the next Eclipse Hackathon!

by Philip Wenig at July 18, 2017 08:24 AM

You only have a few more hours to submit to EclipseCon Europe!

by Cédric Brun ( at July 17, 2017 12:00 AM

I’m deeply honored of being part of the program committee again for EclipseCon Europe 2017.

Each year I’m amazed at this conference, it was one of the first Eclipse event I attend and since then it has always had a strong friendly vibe to it.

In the last few years it evolved into the main international event for the Eclipse community, attending it should be a no brainer.

This conference is great because of the content and the people, help us select good content by submitting it! By my count we already have more than 170 submissions and the usual last minute flood might start any minute from now.

In the next few hours the call for papers will be closed: now is a good time to hit that submit button. Small is beautiful: submit abstracts which are “to the point” are giving clear insight into what content and structure you are proposing. No need for 400 words of context, stick to what makes your submission relevant to EclipseCon and interesting to share.

submit your talk now ! and see you there!

Memories from EclipseCon 2016

You only have a few more hours to submit to EclipseCon Europe! was originally published by Cédric Brun at CTO @ Obeo on July 17, 2017.

by Cédric Brun ( at July 17, 2017 12:00 AM

Eclipse Oxygen Webinars: 6 talks with a total of almost 5 hours

by howlger at July 16, 2017 11:03 PM

Like last year, also this year the Eclipse simultaneous release was accompanied by a series of talks in which developers present their new developments (thanks Kat Hirsch for hosting it). Here is my summary of these six so-called webinars about Eclipse Oxygen; the first three are for IDE users, the other three about Eclipse frameworks:

Lakshmi P Shanmugam:
What’s New in the Eclipse Platform? (57:07)

If you have already seen my 10-minute Oxygen video, you can skip the first half on Eclipse Platform and Java development tools (JDT) improvements. If you watch the talk from the beginning, you can skip the part from 23:11 and 33:18, where the screen sharing is interrupted and afterwards some improvements are shown again. In the second half, Trace Points, which are missing in my video, are explained. Also Plug-in Development Environment (PDE) and the API Tooling improvements are demonstrated. I recommend Java developers to watch at least this and the following video. In addition, you might also watch the three-month old video of the Devoxx talk Eclipse 4.7 Platform News by Lars Vogel (23:38), which gives a deeper insight into some of the Platform, JDT and PDE improvements.

Marc R. Hoffmann:
EclEmma – Code Coverage in Practice (48:57)

AsEclEmma became an Eclipse project, the Java IDE packages are shipped with built-in Java code coverage analysis now. This webinar gives a general introduction to EclEmma, but also shows how to use the Java Code Coverage feature to find unused code or JAR dependencies.
A nice trick is to find the code of a particular function of an application by differential code coverage: launch the application in coverage mode, reset already collected coverage data, execute the function and dump the coverage data. The code executed by the function is shown as covered. At the end of the webinar, some tips are given how common pitfalls can be avoided.

Kaloyan Raev:
PHP Development Tools (PDT) 5.0 (46:26)

This webinar is much more detailed and comprehensive than the Eclipse Newsletter article What’s new in Eclipse PHP Development Tools (PDT) 5.0. In contrast to the previous videos, the improvements are not shown in action, but inmany screenshots. PDT 5.0 supports PHP 7.1 and integrates the Composer (a PHP dependency manager: similar what npm is for node.js or Maven is for Java) as well as PHPUnit. New in PDT are also functions to organize use statements (similar to Organize Imports in JDT). It is nice to know that the activity and diversity with regard to the involved developers and companies is growing. Maybe in a future version code completion proposals will come from a PHP language server instead of as before from PDT. An experimental integration of a PHP language server implemented in PHP already exists. If you want to know more about general Eclipse integration of language servers, see the next webinar.

Sopot Cela and Mickael Istria:
Generic Editor and Language Server Protocol (LSP) (53:55)

At the beginning the new Generic Editor is shown. The Generic Editor is extended by the new LSP4E Eclipse project to support the Language Server Protocol (LSP). The term server is somewhat misleading as the most likely use case will be that the server will be installed and run locally or where the files are (see Mickael’s comment below). The explanation of LSP is followed by the demonstration of two experimental language server integrations, aCute for C# and BlueSky for HTML, CSS, JavaScript and TypeScript files. Although LSP is only about a year old, LSP support has already been announced for 27 languages. Up to now LSP is limited to editing files: no debugging support, no refactorings apart from renaming and no possibility to show a type hierarchy and syntax highlighting is done via TextMate grammars. Like EGit and JGit for Git, the LSP support is realized via the two new Eclipse projects LSP4E and LSP4J, so that not-Eclipse-based applications can use the LSP4J framework. In the next webinar one of such applications is shown.

Sven Efftinge and Miro Spönemann:
New in Xtext: Core Framework, LSP, Tracing Code Generators (51:00)

The webinar starts with the history of Xtext, a framework and tools to build and support domain-specific languages. Since Eclipse IDE lost market share, Xtext support has been extended to IntelliJ IDEA and will be extended to code editors and other IDEs via LSP. The Xtext language server is shown in action in the Eclipse IDE as well in Theia, a cloud and desktop IDE framework implemented in TypeScript. After the demos the new Xtext feature to generate trace code is explained.

Mélanie Bats and Stéphane Bégaudeau:
Eclipse Sirius 5.0, All about UX (32:40)

The last webinar is about Sirius. Sirius is for graphical editors what Xtext is for text editors. The new features are especially – as the title suggests – user experience improvements. They are explained by slides and shown in action. For instance, the decorator mechanism has been improved, e. g. the decorator icons on boxes and on images are placed in such a way that they do not accidentally overlap anymore. There is also an Eclipse Newsletter article about these Sirius user experience improvements, but it is certainly more interesting to see Sirius in action in the webinar.

These were the six Eclipse Oxygen webinars with a total duration of almost five hours, presented by ten people from all over the world. In case this is not enough, check out my Recommended Eclipse Videos playlist. If you have any recommendation for an Eclipse video, please drop a comment.

by howlger at July 16, 2017 11:03 PM

EclipseCon Europe - Wouldn't it be cool to be on stage there?

by Christian Pontesegger ( at July 14, 2017 10:26 AM

I remember my first EclipseCon and how impressed I was by the quality of talks and the technical skills those speakers showed. Proposing a talk of my own was totally out of question.
A year later I thought: "proposing a talk does not harm, it will anyhow get rejected." So I spent 20 minutes on writing the proposal (took me 18 minutes to come up with a fancy title). Some months later I did my first talk at EclipseCon.

EclipseCon does have a lot of technical talks that require deep knowledge of certain aspects of eclipse. However often the most interesting talks are not even technical. I remember a talk from last year: Hearing and Feeling Eclipse - a story about how blind people experience and use our beloved IDE. It is also interesting how companies use Eclipse technology, how to overcome typical obstacles or ideas and proposals on how to improve Eclipse.

Such talks will attract developers and committers and introduce fresh ideas. Besides the audience is great, the spirit is awesome and it is perfect way to get in touch with people that work on similar topics.

Torkild wrote about the free tshirts you get, but he forgot about the beer and the band (which hopefully will also play this year).

So submit your talk right now. Its not a contract yet you have to fulfill, its a proposal :)

by Christian Pontesegger ( at July 14, 2017 10:26 AM

ECF 3.13.7 Oxygen: Maven and Python OSGi Services

by Scott Lewis ( at July 13, 2017 01:54 AM

ECF 3.13.7 has been released as part of the Oxygen Simultaneous Release.  ECF's work recently has emphasized it's implementation of OSGi Remote Services, and the 3.13.7 continues this emphasis.


  1. ECF has multiple distribution providers, and most have been moved to Maven-based builds
  2. Remote Services/RSA is now available via Maven Central, and the Karaf Feature Install uses Maven install.
  3. A new distribution provider that allows Python code as OSGi Services.   See this tutorial for a description.
  4. Many bug fixes and small improvements

by Scott Lewis ( at July 13, 2017 01:54 AM

What’s new in Orion 15.0

by Mike Rennie at July 12, 2017 07:32 PM

After three more months of hard work from committers and our amazing community, we have another great release! This release continued our mission to make Orion as accessible as possible for all developers, included many UX improvements and has a lot of new language tooling features.


We’re continually improving Orion to be the best possible experience for all developers. In Orion 15, we have improved keyboard access, menu navigation and better handling of “splitters”.

Improved tab handling

A substantial amount of work went into making sure that use of the tab key was sensible and properly presented an affordance for its location. Some of the work included:

1. Ensure that all locations that can be tabbed to show a visible ‘focus rect’

Tab focus rectangle

Tab focus rectangle

2. Extend the F2 capability for the editor to show an annotation hover to also show (and put the focus on) any available tooltip for the element with the focus, regardless of the page you’re on (i.e. works on the Git and Settings pages as well now. ESC will return focus to the original element.

F2 focus tab rectangle

F2 focus tab rectangle

3. Make sure that all modal dialogs will ‘trap’ the tab key usage and correctly cycle through the dialogs’ elements.

Improved menu navigation

On the Edit page if the focus is on the main menu you can now use the arrow keys to navigate to any item in the whole menu structure.

Improved splitter manipulation

There is a new command Command + Shift + ‘.’ available that will cycle through each splitter on the page, granting it focus. Once focussed you can use the arrow keys to move the splitter, Enter to toggle the splitter’s ‘thumb’ (if any). ESC will return the focus to the original element.

Code Edit Widget

Override default keybindings

Consumers of the widget now have complete control over the keybindings in use – with improved support to completely override the default bindings the come with Orion.

More details can be found on the in-depth how-to wiki page for the widget.

Language Tools

Docker file support

When working within docker files, Orion 15 now has support for content assist to make things easier. Assist uses the standard Ctrl+space keybinding.

Dockerfile assist

Dockerfile assist

Improved content assist

There have been many improvements in the content assist for other languages as well. For example, assist within CSS files got a substantial overhaul and now provides more complete and correct assist for rules and attributes.

CSS assist

CSS assist

We have also made assist for HTML and JavaScript a bit easier to understand at first glance, by decorating obsolete and deprecated proposals differently than “normal” ones.

Deprecated JavaScript proposal

Deprecated JavaScript proposal

.tern-project hover support

While working in your .tern-project file, you can now hover over entries in the file to get additional information and help.

Tern project file hover

Tern project file hover

package.json hover support

While working in your package.json file, you can now hover over entries in the file to get additional information and help.

package.json hover

package.json hover

.eslintrc hover support

While working in your eslint configuration file(s), you can now hover over entries in the file to get additional information and help.

ESLint hover

ESLint hover

The hover support for ESLint configuration entries is also available within your package.json file in the eslintConfig section. The hover support is not available yet in the *.yml and *.yaml variants of the ESLint configuration files.

Third party Tern plug-ins

Adding a Tern plug-in to Orion that is not part of the codebase has always been challenging. First you would have to modify the JavaScript tools code, rebuild Orion yourself and then deploy it yourself. In Orion 15 though, you can now load a plug-in directly from your workspace or another location.

The complete details can be found on the bug, but the general scheme is:

  1. you can load a Tern plug-in from a hosted location or the .tern-plugins folder within your project
  2. you plug-in can contribute to all the normal passes and callbacks from Tern
  3. your plug-in must be declared via the .tern-project file

Platform Improvements

JavaScript project information

If you select a project in the navigator, Orion now has support to show you what the JavaScript tools thinks about the configuration of the project. The new information is shown in the JavaScript section and contains helpful information about what ECMA level is being used to parse, etc. There are also handy links to common configuration files (if they are present in the project).

JavaScript project information

JavaScript project information

Updated “Hide system files from the navigator ” preferences

Rather than having to type out all of the names of resources you want to be filtered from the explorer views, we have updated the preference to support wildcards like ? and *.

Editor tab support

Finally. After all this time, we have support in Orion for multiple editor tabs! By default Orion still works in the “one editor per browser tab” mode, but you can start using editor tabs by simply turning on the preference in the General prefs section.

Orion editor tabs preference

Orion editor tabs preference

Once enabled, you can open multiple files within a single editor, rather than have multiple browser tabs open. Tabs can be closed, dragged, reordered, and switched to using convenient keybindings.

Multiple editor tabs

Multiple editor tabs

Custom Themes

Plugins can now contribute their own themes to style Orion. All of the information related to the new orion.core.container.themes.provider service can be found on the API documentation wiki page.

Multiple workspaces

The Orion platform now has support for multiple workspaces! This allows consumers of Orion to better organize their files by having multiple source repositories spread across multiple workspaces instead of one gigantic workspace filled with many unrelated repositories.

By default Orion does not have end-user support to create and manage multiple workspaces, so third party support is required.

Node.js Server

A lot of work went into making the Node.js server more stable and making sure it was feature-complete compared to its Java version.

Git rebase skip support

Support for skipping conflicting commits during rebase has been added to the server.

Git squash support

The ability to squash commits into the index has been added to the server.

Move to Github

As we talked about in a previous post, during 15.0 we moved all of our source to Github. If this is the first time you are hearing about the move, then head over to the post, and give it a read for all the details about where to find our code and how to contribute.

by Mike Rennie at July 12, 2017 07:32 PM

EclipseCon Europe 2017: Get your talk proposals in now!

by Torkild at July 11, 2017 09:19 PM

For the twelfth year in a row there is an Eclipse conference in Germany this October – I have to admit it’s my favourite conference; friendly faces everywhere, good food, awesome keynotes, great talks, and even a band to dance to during the reception.

Again we expect more than 600 attendees in the lovely small town of Ludwigsburg, not far from Stuttgart. In order to fill three days with activities and interesting talks, we need your help. There is still a few days to get your submissions in, as the deadline is the 17th of July. So what we want you to do, is to sit down and type in a short abstract for something you would like to present. Look at the Call for Papers, to see if your idea can fit into one of the categories. Just go ahead and type away, let the program committee worry about whether or not your proposal is good enough. If your talk is selected, you will not have to pay the entrance fee and will have some leverage with your boss when discussing whether or not you can go. Oh, and you’ll get a nice speakers T-Shirt 😄

See you there!

by Torkild at July 11, 2017 09:19 PM

EclipseCon 2017 – last chance to submit a talk!

by Maximilian Koegel and Jonas Helming at July 11, 2017 04:24 PM

The deadline for submitting to EclipseCon Europe 2017 is approaching. The last day is Monday, June 17. Please find the submission system here.

Don’t miss the chance to give a talk on a great event and share your thoughts with a wonderful audience!

Are you a committer? Come and tell us what is new and noteworthy in your project! Are you involved with interesting web technologies or tools? Then choose our revised “Web and Cloud Development” track. Do you use Eclipse as a basis for your own project? Submit your experience in the new category “Build on Eclipse.” Are you a Java expert? Tell us about interesting topics related to Java and/or JDT! Please see here for a complete list of tracks.

Most importantly, do it now! Otherwise it will be too late!

by Maximilian Koegel and Jonas Helming at July 11, 2017 04:24 PM

How to fix Artop memory problems

by Andreas Graf ( at July 11, 2017 01:30 PM

In the automotive domain, itemis and others make intensive use of the community project Artop (Autosar Tool Platform) – an Eclipse (EMF) based implementation of the AUTOSAR meta-model. Artop supports the conversion of models between the many revisions of the AUTOSAR standard. 

We have encountered situations, where an Artop based application needs huge amounts of memory – here is an analysis of the technical reasons.

AUTOSAR revision conversion: Illustration of brain concept with triangular grid

AUTOSAR revisions and Artop revision conversion

Any given product built on top of Artop will make use of a specific implementation of the AUTOSAR meta-model (e.g. 4.3.1). Artop supports the conversion between these revisions upon loading and saving (i.e. from or to 4.3.0). In our case, the application is based on a custom built Artop for some internally used pre-released AUTOSAR versions. We work on a revision called 4.3.1, but we also have to save 4.3.0.

Upon saving Artop will do a conversion in the following steps:

  1. The standard Eclipse/EMF implementation will create a memory-optimized XML-representation of the AUTOSAR model (a XMLStringImpl instance). This is used to avoid duplication of string values.
  2. Artop will then take this as an input and create a JDOM representation of the XML internally.
  3. Artop will invoke the revision converter for all elements of the JDOM tree, to allow for conversion (this is specific for each combination of from/to revisions).
  4. Artop will finally serialize the resulting JDOM to disk as XML.

With production data, we have seen Artop consume huge amounts of memories. One of the reasons is the JDOM representation as created in Step 2.


Obviously the quickest fix is to increase the memory available to the JVM with the -Xmx option. However, we still had memory problems and have started to create patches for Artop.

Minimal invasive fix

We have several approaches, with different impacts on Artop architecture. Our first fix concentrates on minimizing the memory required by the JDOM model. It seems that the JDOM creation is not memory optimized and each JDOM element created uses its own string instances. JDOM2 provides a JDOM builder with string caching, which is not available to us. So we created our own implementation making use of Java 7 / Java 8's improved String interning.

While we were at it, we also simplified Artop a bit: The original code uses an additional thread (for technical reasons) for creating the JDOM – we were able to remove that by implementing a simple Reader class that takes data directly from the XMLStringImpl.

Possible Redesign

Since EMF does not only support using the XMLStringImpl for serialization, but also using the DOM classes from the w3c packages, it could be an optimization to use those directly. But since the conversion APIs are based on JDOM, this will need API changes (converting w3c DOM to JDOM does not seem to be an option, since we would be duplicating DOM trees, again).


In a combination of increasing available memory and reducing the memory footprint with our patches, we resolved the out-of-memory issues. In situations like these, we not only built products and toolchains on top of Artop, but also work actively to improve the overall code base for the community.

You want to learn more about our projects in the automotive domain?

Check our blog for more information


by Andreas Graf ( at July 11, 2017 01:30 PM

EclipseCon Europe 2017 | Submissions Close in One Week

July 10, 2017 01:05 PM

There’s still time until July 17th, to get your submission in for this year’s EclipseCon Europe in Ludwigsburg Germany.

July 10, 2017 01:05 PM

EclipseSource Oomph Profile – updated to Oxygen

by Maximilian Koegel and Jonas Helming at July 07, 2017 08:28 AM

Last week, Oxygen has been release, a new major version of the Eclipse IDE. It contains many useful improvements, so it is worth to update. In case you use our EclipseSource Oomph profile (see here for more details), you should get a notification and Oomph will apply the update automatically. If you do not get the notification, just navigate to the menu entry “Window” => “Perform Set-Up Task”.

This will automatically update all plugins to Oxygen, but keep all existing settings untouched.

In the meantime, we added one new default setting to our EclipseSource profile:

This will include all bundles when using the “Open Type” dialog, not only the ones in the current scope.

Have fun with Oxygen!

by Maximilian Koegel and Jonas Helming at July 07, 2017 08:28 AM

Linking Xtext Models With EMF Models

by Jan Köhnlein at July 06, 2017 12:43 PM

This article shows the necessary steps to enable cross-references between Xtext models and other EMF based models. It focusses on the linking aspects, and keeps things like the synchronization, transactions, singleton editing domains, dirty-state handling etc. aside. So for a full integration, let’s say with Sirius, this is only one part of the story.

There are often good reasons to describe different parts of an EMF model in different notations, e.g. textual and graphical. To connect resources with different notations we can use EMF cross-references. Via the XtextResource, Xtext hides the entire process of parsing (text to EMF) and serialization (EMF to text) behind EMF’s resource API. So in theory, cross-references between Xtext and other EMF-based models should work out-of-the-box, shouldn’t they?

Unfortunately, there is one big difference: Xtext uses names to refer to an element, while EMF uses URIs. This blogpost is about how to get cross-references working anyway.

The Example

We’ve put an example on Github, where we use simple Ecore model for trees and an Xtext grammar on the same model.

Screen Shot 2017-07-06 at 13.51.58Screen Shot 2017-07-06 at 13.55.19

In our setup, we can define tree models either in XMI using the generated EMF tree editor (file extension tree) or textually in an Xtext (file extension xtree), and establish cross-references between the models of both notations. The screenshot shows an XMI-based model on the left and an Xtext-based on the right refering to each other.
Cross-references between Xtext and XMI

Cross-References from Xtext to XMI

To resolve a cross-reference to an element, Xtext takes the name given in the text to look up the referred element in a scope. You can think of a scope as a table of all candidates for a certain cross-reference with their name in a specific context. Scopes are usually chained, such that if the current scope does not yield a result for a given name, it asks its parent scope and so on. The top-most parent scope is called the global scope. It provides all elements from all reachable resources that would be referable at that specific location. It is usually backed by the Xtext index, which stores descriptions of all externally referable elements for each resource. The index is populated by the Xtext builder, which automatically syncs the index data on file changes. This is why you should never deactivate automatic builds for an Xtext project. More information on scoping can be found in the Xtext documentation.

Given the above, in order to refer to XMI from Xtext we have to create index entries for the elements of the XMI-based model. This is achieved by registering a new language for the *.tree resources to the Xtext infrastructure, thus providing services like indexing and name computation. In the example, we created a separate plug-in project for the Xtext language registration. You could of course put that code in an existing plug-in as well. or you might want to put runtime and UI parts into separate plug-ins.

  1. Implement a TreeRuntimeModule inheriting from AbstractGenericResourceRuntimeModule and implement the missing methods. This class is used to configure the runtime dependency injection (DI) container for this language. If you want to override non-UI services you can do this here.
    In our example, we override the IQualifiedNameProvider to yield fully qualified names, i.e. Root.Child instead of just Child in the above example to avoid name collisions.
  2. Implement a TreeUiModule inheriting from EmfUiModule. This is the DI config for all Eclipse-based services.
    In the example, we added an editor opener that opens the EMF tree editor when the user follows a reference to an XMI-defined tree element in the Xtext editor.
  3. Implement a plug-in Activator (inheriting from AbstractUIPlugin) that creates the injector based on the TreeUiModule, the TreeRuntimeModule and the common SharedStateModule on start(). Make sure to register the Activator in the MANIFEST.MF.
  4. Implement an TreeExecutableExtensionFactory that extends AbstractGuiceAwareExecutableExtensionFactory and delivers both the bundle and the injector from the Activator.
  5. In the plugin.xml, register your language to the extension point org.eclipse.xtext.extension_resourceServiceProvider with the uriExtension tree and an instance of EmfResourceUIServiceProvider created via the TreeExecutableExtensionFactory from the previous step.

You could skip step 2 to 5 if you don’t need Eclipse support. If you want to have the same functionality in a plain Java process, you have to manually create the injector and initialize the EMF registries, as we did in the TreeStandaloneSetup.

Cross-References from XMI to Xtext

As opposed to names in Xtext, EMF uses URIs to refer to elements. In XMI, the standard serialization format for EMF models, a cross-ref becomes an href with the URI of the referred element. The URI consists of the URI of the resource where the element is defined in, followed by the fragment which is a resource unique string identifier of the element, e.g.


The XtextResource delivers such URIs for all contained elements by default. These URIs are picked up by referring XMI resources, so it seems like this works out-of-the-box. But the problems begin as soon as you start modifying the referred Xtext resource.

The default algorithm for computing the fragments uses an Xpath expression, navigating the containment features from the root element by name (children) and index (1). This approach delivers unique fragments for all elements in a resource without relying on a name or a unique ID attribute. The disadvantage is, that it assumes that the position of an element in the content tree is fixed. When we switch the order of Bar and Baz in the example, their path fragments would be switched as well, screwing up existing URI references to them.

If you want the same linking semantics as in Xtext, the fragment should encode the fully qualified name of the element. Xtext allows you to customise that by implementing your own IFragmentProvider. In the example, we have added our own XtreeFragmentProvider and bound it in the XtreeRuntimeModule.

Additionally we might want to include the element’s EClass, because elements of different types in the same model could have the same name. Then, there can be multiple EClasses in different EPackages with the same name, so a complete generic solution for the fragment would be a fully qualified EClass name followed by a fully qualified element name
that is

href="[resource URI]#[EPackage nsURI][separator][EClass name][separator][EObject FQN]"



This is a lot of information to be packed into a string. We also must sure we don’t break encoding rules. So it may be better to go for a less general, domain-specific solution as we did in the example.

Another problem is the resource part of the URI: In Xtext, a referrer does not care in which resource the cross-referenced element is. Moving an element to a different Xtext resource would break all URI-based links to it, while the name-based links stay intact. A possible solution would be to implement a move refactoring for Xtext elements. That is beyond the scope of this article.

A Word on Rename Refactoring

In URI-based linking, renaming an element will not change a cross reference, as long as the fragments don’t involve the name. With our approach, the links to the Xtext resource are susceptible to such renames.

The good news is that by registering the tree language to Xtext as we did above, cross-references to Xtext elements will be automatically updated when the user triggers a rename refactoring on them.

The bad news is that the links from Xtext to XMI will break when an XMI element is renamed, let’s say in the EMF tree editor. It is up to the implementor of the editor to trigger the a rename refactoring for referring Xtext resources on such user actions if that is the intended behavior. Luckily, broken links from Xtext to XMI will just be marked as errors and can be easily fixed by hand.

by Jan Köhnlein at July 06, 2017 12:43 PM

Clean Sheet Update for Eclipse Oxygen

by Frank Appel at July 06, 2017 12:05 PM

Written by Frank Appel

In celebration of the latest Eclipse release, there is a Clean Sheet Update for Eclipse Oxygen available. Congratulations and a big ‘thank you’ to all the diligent Eclipse committers and contributors that made the Oxygen version happen, great work! The Clean Sheet Update for Eclipse Oxygen primarily ensures compatibility but provides also a minor facelift and bug fix. The current version is 0.6.0. Note that this release drops support for Eclipse Mars (4.5).


The Clean Sheet Eclipse Design

In case you've missed out on the topic and you are wondering what I'm talking about, here is a screenshot of my real world setup using the Clean Sheet theme (click on the image to enlarge). Eclipse IDE Look and Feel: Clean Sheet Screenshot For more information please refer to the features landing page at, read the introductory Clean Sheet feature description blog post, and check out the New & Noteworthy page.


Minor Facelift of Main Toolbar

The main toolbar has been lightened up a bit to show off the action icons to their best advantage.

Clean Sheet Update for Eclipse Oxygen: Toolbar Facelift

Java Editor Font Size on Mac

The default Java editor font-size on Mac OS has been increased due to remarks that it was a bit too small with previous versions.

Clean Sheet Update for Eclipse Oxygen: Default Font Size Mac OS

On a Final Note, …

Of course, it’s interesting to hear suggestions or find out about potential issues that need to be resolved. In particular, as it’s not possible to test all available features with a new IDE version. Feel free to use the Xiliary Issue Tracker or the comment section below for reporting.

With this in mind, I’d like to thank all adopters for the support and hope the Clean Sheet Update for Eclipse Oxygen will continue to measure up to your expectations 😉

The post Clean Sheet Update for Eclipse Oxygen appeared first on Code Affine.

by Frank Appel at July 06, 2017 12:05 PM

Chromium / Eclipse SWT integration

by Mikaël Barbero at July 04, 2017 02:27 PM

Key takeaways:
Do you want to see a Chromium based SWT Browser implementation? Please donate (or reach out to me if you want to do corporate donations) and the Eclipse Foundation will make it happens via the Friends of Eclipse Enhancement Program (FEEP).

Browser support in SWT has always been a complicated story. By default (meaning without any hint from the application developers and the users), SWT relies on “native” renderers (Internet Explorer on Windows, WebKit on macOS and WebKitGTK+ or Mozilla/XULRunner on Linux). While supporting different rendering of pages in the Web is common, it’s annoying when you develop a desktop application where the Browser component is used to render things that Web technologies can do better than SWT (CSS, SVG, WebGL, etc.). Not only that, but you would expect high performance from the renderer for such usage.

To mitigate these discrepancies, developers can provide some hints to the SWT framework about which renderer (WebKit or Mozilla/XULRunner) it should use. Unfortunately, XULRunner is deprecated and is no longer built/shipped by the Mozilla team. WebKit is staying, but it brings its own couple of issues when one tries to use it on all platforms:

  • On Windows, it requires users to have Safari installed. As you may know, Apple has silently killed Safari on Windows back in 2012. Moreover, Safari was only available on 32 bits Windows systems. All in all, you don’t really have a choice: you need to rely on the Internet Explorer renderer when using Windows.
  • On Linux, it can be difficult to setup a proper working combination of WebKitGTK and GTK+. It is especially true for older Eclipse versions on Linux distros which change GTK+ internals (hello Ubuntu!).
  • On macOS, it just works™, as expected (it would have been a surprise where the system renderer is WebKit itself).

For more details on the compatibility of all platforms, you should read the Browser section of the SWT FAQ).

One solution that has been studied further is implementing the SWT Browser widget on top of the JavaFX browser component (WebView). Unfortunately, it has some compatibility issues with GTK+ versions. Furthermore, it is reported to be slow and to have trouble rendering modern HTML pages due to the usage of an old version of WebKitGTK.

So here comes the idea to embed Chromium (the open source project behind the Google Chrome browser). It is available on all major platforms (Windows, Linux and macOS), it is known for its high performance and high quality rendering. On top of that, most of the Chromium packaging for embedding is done by the Chromium Embedded Framework (CEF). CEF is quite successful and is used by some famous applications like Spotify, Steam Client and Evernote. It is also the foundation of the Electron project (extracted from the text editor Atom). It is so successful and widespread that the Mozilla Foundation’s new renderer (Servo/Quantum) has adopted the CEF API for developers to embed it.

There have been several attempts to bring CEF to Java and SWT, but none were really successful. The Eclipse Foundation has been looking for talented developers to take over these efforts and to make it happen. Thanks to the Friends of Eclipse Enhancement Program, a call for bidding has been created in early 2017. The awesome people from Make Technology have replied to it and demonstrated that they have the skills to do it. They already have a working prototype in the following GitHub repositories:

They also have a rock solid plan and they have created umbrella bugs for each milestone of this work:

This requires an enormous amount of work and unfortunately, we did not receive enough donations this year to fund the project. If you want to see this work happen for the Eclipse Platform, please donate or reach out to me if you want to do corporate donations, or to learn more about corporate donations.

by Mikaël Barbero at July 04, 2017 02:27 PM

OpenAPI (fka Swagger) 3 support in Eclipse Vert.x now in test stage!

by slinkydeveloper at July 04, 2017 12:00 AM

As GSoC 2017’s student, I’m actually working on an embedded support to OpenAPI 3 standard inside Eclipse Vert.x framework. Now, after a lot of work, you can try it!

Why OpenAPI 3?

OpenAPI 2 is the most important industry-grade standard for API Specifications. As you can see on official blog of OpenAPI Initiative, the release of version 3 is behind the corner, so we want to give to our community the latest tools for the latest standards!

Vert.x project objective is to give you more integrated tools. With this new support, it gives you the ability to use the Design Driven (or Design First) approach without loading any thirds parties libraries.


The actually supported features are the following (we refeer to document Version 3.0.0-rc2):

  • OpenAPI 3 compliant API specification validation (thanks to Kaizen-OpenApi-Parser) with loading of external Json schemas
  • Automatic request validation
  • Automatic mount of security validation handlers
  • Automatic 501 response for not implemented operations
  • Router factory to provide all this features to users

Automatic request validation is provided by a new handler: ValidationHandler. You can also define your own ValidationHandler without API specifications, but I will discuss it later.

The request validation (provided by subclass OpenAPI3RequestValidationHandler) actually supports:

  • Parameters defined in Parameter object. We support every type of parameter, including object and array. We also support every type description field (for example format, minimum, maximum, etc). Also, at the moment, we support every combination of style and explode field (excluded styles matrix and label)
  • Body defined in new RequestBody object. In particular:
    • For application/json the validation handler will take schema that you have defined in schema object and will validate json bodies with it
    • For application/x-www-form-urlencoded and multipart/form-data the validation handler will take care of validate every parameters in form attributes. It actually supports only comma separated values for object and arrays
    • For other parameter types it will check Content-Type header

Request validation errors will be carried with RoutingContext encapsulated in an object called ValidationHandler, so you have to attach failure handler to check if something went wrong during validation. Also the RoutingContext carry a new object called RequestParameters that encapsulate all request parameters deserialized and parsed.

Router factory is intended to give you a really simple user interface to use OpenAPI 3 support. Most important features are:

  • Async loading of specification and its schema dependencies
  • Automatic convert OpenAPI style paths to Vert.x style paths
  • Lazy methods: operations (combination of paths and HTTP methods) are mounted in definition order inside specification
  • Automatic mount of security validation handlers

Also, it’s planned to release a project skeleton generator based on API spec.

Startup your project

We are in a testing stage, so the vertx-web official repo doesn’t contain it. To include the modified version of vertx-web replace your vertx-web maven dependency with this one:

Then you have to add this maven repository in your `pom.xml`

You can also use it with gradle

Now you can start using OpenAPI 3 inside your Vert.x powered app!

First of all you need to load the specification and construct the router factory:

// Load the api spec. This operation is asynchronous
OpenAPI3RouterFactory.createRouterFactoryFromFile(this.vertx, "src/main/resources/petstore.yaml", ar -> {
    if (ar.succeeded()) {
        // Spec loaded with success
        OpenAPI3RouterFactory routerFactory = ar.result();
    } else {
        // Something went wrong during router factory initialization
        Throwable exception = ar.cause();
        logger.error("Ops!", exception);

Handlers mounting

Now load your first path. There are two functions to load the handlers:

  • addHandler(HttpMethod method, String path, Handler handler, Handler failureHandler)
  • addHandlerByOperationId(String operationId, Handler handler, Handler failureHandler)

This two functions wants an handler and a failure handler. You can, of course, add multiple handlers to same operation, without overwrite the existing ones.

Add operations with operationId
Usage of combination of path and HTTP method is allowed, but it’s better to add operations handlers with operationId, for performance reasons and to avoid paths nomenclature errors

This is an example of addHandlerByOperationId():

// Add an handler with operationId
routerFactory.addHandlerByOperationId("listPets", routingContext -> {
    // Handle listPets operation (GET /pets)
}, routingContext -> {
    // Handle failure

This is an example of addHandler:

// Add an handler with a combination of HttpMethod and path
routerFactory.addHandler(HttpMethod.POST, "/pets", routingContext -> {
    // Handle /pets POST operation
}, routingContext -> {
    // Handle failure

Request parameters

Now you can freely use request parameters. To get the RequestParameters object:

RequestParameters params = routingContext.get("parsedParameters");

The RequestParameters object provides all methods to access to query, cookie, header, path, form and entire body parameters. Here are some examples of how to use this object.

Parameter with name awesomeParameter with type integer in query:

RequestParameter awesomeParameter = params.queryParameter("awesomeParameter");
if (awesomeParameter != null) {
    // awesomeParameter parameter exists, but we are not sure that is empty or not (query parameters can be empty with allowEmptyValue: true)
    if (!awesomeParameter.isEmpty()) {
      // Now we are sure that it exists and it's not empty, so we can extract it
      Integer awesome = awesomeParameter.getInteger();
    } else {
      // Parameter exists, but it's empty value
} else {
    // Parameter doesn't exist (it's not required)

As you can see, every parameter is mapped in respective objects (integer in Integer, integer with format: int64 in Long, float in Float and so on)

Comma separated array with name awesomeParameters with type integer in query:

RequestParameter awesomeParameters = params.queryParameter("awesomeParameters");
if (awesomeParameters != null && !awesomeParameters.isEmpty()) {
    List awesomeList = awesomeParameters.getArray();
    for (RequestParameter awesome : awesomeList) {
      Integer a = awesome.getInteger();
} else {
  // awesomeParameters not found or empty string

JSON Body:

RequestParameter body = params.body();
if (body != null)
  JsonObject jsonBody = body.getJsonObject();

Security handling

You can mount only one security handler for a combination of schema and scope.

To add a security handler only with a schema name:

routerFactory.addSecurityHandler("security_scheme_name", routingContext -> {
    // Handle security here and then call next();

To add a security handler with a combination of schema name and scope:

routerFactory.addSecuritySchemaScopeValidator("security_scheme_name", "scope_name", routingContext -> {
    // Handle security here and then call next();

You can define security handlers where you want but define it!
During Router instantiation, if factory finds a path that require a security schema without an assigned handler, It will throw a RouterFactoryException

Error handling

Every time you add an handler for an operation you can add a failure handler. To handle a ValidationException:

Throwable failure = routingContext.failure();
if (failure instanceof ValidationException)
    // Handle Validation Exception

Also the router factory provides two other tools:

  • It automatically mounts a 501 Not Implemented handler for operations where you haven’t mounted any handler
  • It can load a default ValidationException failure handler (You can enable this feature via routerFactory.enableValidationFailureHandler(true))

And now use it!

Now you are ready to generate the Router!

Router router = routerFactory.getRouter();

// Now you can use your Router instance
HttpServer server = vertx.createHttpServer(new HttpServerOptions().setPort(8080).setHost("localhost"));

Lazy methods!
getRouter() generate the Router object, so you don’t have to care about code definition order

And now?

You can find a complete example here: OpenAPI 3 Vert.x example gists

You can access to documentation (WIP) here (for others languages, check out here), but you can also check Javadoc inside code. These are the most important ones:

Follow my fork of vertx-web project to get last updates.

We want you!
Please give us your feedback opening an issue here

by slinkydeveloper at July 04, 2017 12:00 AM

Announcing Handly 0.7

by Vladimir Piskarev at June 30, 2017 07:47 PM

We are pleased to announce the availability of Eclipse Handly 0.7 release, which contains a number of enhancements in Core API.

New and Noteworthy
Migration Guide

The 0.7 release has been informed in a large part by trying to adopt Handly in a specially created experimental fork of Eclipse Java development tools (JDT) to test the core framework in the context of a non-trivial, well-known existing model implementation, the Java model. The JDT Core component has a comprehensive suite of JUnit tests, including nearly 8 000 tests specifically for the Java model. All of the Java model tests, including performance tests, run successfully in the Handly-based fork now. None of the existing public JDT APIs have been affected in any way. Notably, most of the internal JDT (non-)APIs have also been kept intact. We humbly hope that it can serve as a real-world example of what Handly is capable of now and help encourage further adoption. Broader community feedback and participation would be most welcome.

by Vladimir Piskarev at June 30, 2017 07:47 PM

Announcing Orion 15

by Grant Gayed at June 30, 2017 06:04 PM

We are pleased to announce the fifteenth release of Orion, “Your IDE in the Cloud”. You can run it now at 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 191 bugs and enhancements fixed, across 367 commits from 18 authors!

This release was focussed on making improvements in the Node.js server and Electron app, and progressing on adding collaborative development support and debugging support directly in Orion. Additionally, the Orion repos have now moved to (client and server).

The improvements in the Node.js server will see it soon replace the Java server as the preferred implementation. The new work on adding collaborative development support and debugging support directly in Orion is not quite ready for prime time, but should officially land in Orion 16.

by Grant Gayed at June 30, 2017 06:04 PM

JBoss Tools 4.5.0.AM1 for Eclipse Oxygen.0

by jeffmaury at June 30, 2017 03:34 PM

Happy to announce 4.5.0.AM1 (Developer Milestone 1) build for Eclipse Oxygen.0.

Downloads available at JBoss Tools 4.5.0 AM1.

What is New?

Full info is at this page. Some highlights are below.

Server Tools

EAP 7.1 Server Adapter

A server adapter has been added to work with EAP 7.1. It’s currently released in Tech-Preview mode only, since the underlying WildFly 11 continues to be under active development with substantial opportunity for breaking changes. This new server adapter includes support for incremental management deployment like it’s upstream WildFly 11 counterpart.

Removal of Event Log and other Deprecated Code

The Event Log view has been removed. The standard eclipse log is to be used for errors and other important messages regarding errors during server state transitions.

Hibernate Tools

Hibernate Search Support

We are glad to announce the support of the Hibernate Search. The project was started by Dmitrii Bocharov in the Google Summer Code program and has been successfully transferred in the current release of the JBoss Tools from Dmitrii’s repository into the jbosstools-hibernate repository and has become a part of the JBoss family of tools.


The plugin was thought to be some kind of a Luke tool inside Eclipse. It was thought to be more convenient than launching a separate application, and picks up the configuration directly from your Hibernate configuration.

Two options were added to the console configurations submenu: Index Rebuild and Index Toolkit. They become available when you use hibernate search libraries (they exist in the build path of your application, e.g. via maven).

Configuration menu items
Index Rebuild

When introducing Hibernate Search in an existing application, you have to create an initial Lucene index for the data already present in your database.

The option "Index Rebuild" will do so by re-creating the Lucene index in the directory specified by the property.

Hibernate Search indexed entities
Hibernate Search configuration properties
Index Toolkit

"Open Index Toolkit" submenu of the console configuration opens an "Index Toolkit" view, which has three tabs: Analyzers, Explore Documents, Search.


This tab allows you to view the result of work of different Lucene Analyzers. The combo-box contains all classes in the workspace which extend org.apache.lucene.analysis.Analyzer, including custom implementations created by the user. While you type the text you want to analyse, the result immediately appears on the right.

Explore Documents

After creating the initial index you can now inspect the Lucene Documents it contains.

All entities annotated as @Indexed are displayed in the Lucene Documents tab. Tick the checkboxes as needed and load the documents. Iterate through the documents using arrows.

Lucene Documents inspection

The plugin passes the input string from the search text box to the QueryParser which parses it using the specified analyzer and creates a set of search terms, one term per token, over the specified default field. The result of the search pulls back all documents which contain the terms and lists them in a table below.

Search tab



Docker Client Upgrade

The version of docker-client used by the Docker Tooling plug-ins has been upgraded to 6.1.1 for the 3.0.0 release of the Docker Tooling feature.


Forge Runtime updated to 3.7.1.Final

The included Forge runtime is now 3.7.1.Final. Read the official announcement here.



Jeff Maury

by jeffmaury at June 30, 2017 03:34 PM