Skip to main content

Eclipse Che 7 Enables Faster, Safer Development on Kubernetes

by Mike Milinkovich at September 17, 2019 02:00 PM

A major version release within the Eclipse Foundation community always provides us a reason to celebrate, congratulate, and thank all those who participated and contributed to the process. The delivery today of Eclipse Che 7 is no exception. But Che 7’s arrival is more than great news for the Eclipse community, it’s also an industry game changer because it drastically reduces the learning and adoption curves of Kubernetes for enterprise application developers.

Che 7 is the result of more than six years of collaboration and community contributions, including more than 20 vendors. It’s the world’s first Kubernetes-native IDE that has been built from the ground up specifically to enable developers to build cloud native applications. Fundamentally, Che 7 makes the developer and production environments the same on a scalable, collaborative, and secure platform specifically designed for building containerized applications. That platform addresses the major challenges developers face when working with Kubernetes.

While Kubernetes does a fantastic job of operating applications at scale, it’s a complex system that most developers do not yet fully understand. With Che 7, the workspace configuration complexities and challenges developers face with Kubernetes have been eliminated. The platform can be deployed on a public Kubernetes cluster or an on-premises data center. Once deployed, it provides centrally hosted private developer workspaces that make projects easy to share and easy to manage, but with enterprise-grade security.

Che 7 takes care of the “Kubernetization” of the development environment and the applications that a developer is building. It comes with a pre-packaged web-based IDE, based on an extended version of Eclipse Theia to provide an in-browser Visual Studio Code experience. The fully integrated environment containerizes everything a developer needs to develop, build, run, test, and debug enterprise cloud native applications. This includes all of the tools and dependencies. This a big deal considering many enterprises cite a lack of integration of development tools and processes as a primary challenge of container adoption.

The introduction of Che 7 represents another milestone in enterprise-grade, cloud native tooling innovation from the Eclipse Foundation and our community. It continues the Eclipse Foundation track record of delivering innovative tools to the development community, most notably through the Eclipse desktop IDE. Che is already integral to cloud native solutions from our vendor community, including Google, IBM, and Broadcom. It also comprises the core of Red Hat CodeReady Workspaces, a new development environment for Red Hat OpenShift.

As we move forward, our community will continue to deliver more innovation through the Eclipse Cloud Development (ECD) Tools Working Group. In addition to Che, the ECD WG encompasses a broad portfolio of open source cloud development projects including Theia, Eclipse CodeWind, Eclipse Dirigible, Eclipse Sprotty, Eclipse Orion, and many more. The ECD WG will drive the evolution and adoption of de facto standards for cloud development tools, including language support, extensions, and developer workspace definitions.

Of course, Che 7 and the ECD WG are made possible by our development community. So, I thank all of those who have participated to date and encourage everyone to take part in the innovation process. To that end, we are actively recruiting members to the Eclipse Cloud Development Working group and we encourage and welcome new members.

Get started with Che 7 on any Kubernetes cluster at or learn more about getting started with Che at To get involved with the Che community and contribute to the project, visit:


by Mike Milinkovich at September 17, 2019 02:00 PM

The Eclipse Foundation Wins Duke's Choice Award for Open Source Contributions to the Java Ecosystem

September 17, 2019 02:00 PM

The Eclipse Foundation was awarded a Duke's Choice Award yesterday in recognition for outstanding open source contributions to the Java ecosystem and the community-driven achievement of moving Java EE technologies from Oracle to the Jakarta EE Working Group.

September 17, 2019 02:00 PM

Eclipse Community Continues to Deliver on Open Source Commitment

September 17, 2019 02:00 PM

Community is key. And the Eclipse Foundation's community is on a roll.

September 17, 2019 02:00 PM

Eclipse Community Continues to Deliver on Open Source Commitment

by Thabang Mashologu at September 17, 2019 01:01 PM

Community is key. And the Eclipse Foundation’s community is on a roll.

With all the work of the various working groups, market launches, and now awards, it’s sometimes an effort just to keep up with all the activity. This month is no exception.

Last night at the Oracle Code One conference, our executive director, Mike Milinkovich, accepted the Duke’s Choice Award on behalf of the Jakarta EE community. The Eclipse Foundation’s Jakarta EE Working Group was recognized for outstanding open source contributions to the Java ecosystem.

Now in its 17th year, the Duke’s Choice Awards celebrate invaluable innovation in Java-based technologies and contributions to Java. We’re thrilled with the award for Jakarta EE because there is no greater recognition of an achievement than the recognition that comes from colleagues and industry peers. On behalf of everyone at the Eclipse Foundation, thank you and congratulations to the dedicated members of the Jakarta EE community!

Beyond the award, last night’s news comes on the heels of the community’s successful launch of Jakarta EE 8 last week and the launch today of Eclipse Che 7.

Last week, under an open, vendor-neutral process, a diverse community of the world’s leading Java organizations, hundreds of dedicated developers, and Eclipse Foundation staff delivered the Jakarta EE 8 Full Platform and Web Profiles, and related TCKs, as well as Eclipse GlassFish 5.1 certified as a Jakarta EE 8-compatible implementation. With 18 different member organizations, over 160 new committers, 43 projects, and a codebase of over 61 million lines of code in 129 Git repositories, this was truly a massive undertaking — even by the Eclipse community’s standards.

Jakarta EE 8 offers an unprecedented opportunity for Java stakeholders to participate in advancing Jakarta EE to meet the modern enterprise’s need for cloud-based applications that resolve key business challenges. The community now has an open source baseline that enables the migration of proven Java technologies to a world of containers, microservices, Kubernetes, service meshes, and other cloud-native technologies that have been adopted by enterprises over the last few years. 

We also published a new eBook, Fulfilling the Vision for Open Source, Cloud Native Java. This free publication explores our community’s perspective on what cloud native Java is, why it matters so much to so many enterprises, and where Jakarta EE technologies are headed. If Java is important to your organization, download this eBook now.

While all the preparations were being put in place for the launch of Jakarta EE 8, our team was also preparing for the release of Eclipse Che 7 earlier today.

Eclipse Che 7 is the world’s first Kubernetes-native IDE that has been built from the ground up specifically to enable developers to build cloud native applications. It makes the developer and production environments the same on a scalable, collaborative, and secure platform specifically designed for building containerized applications. And it addresses the major challenges developers face when working with Kubernetes.

Che 7 is a game changer because it enables faster, safer development with Kubernetes. The platform significantly simplifies writing, building, and collaborating on cloud native applications. It drastically reduces the learning and adoption curves of Kubernetes for enterprise application developers. It closes the gap between development and production environments. Most importantly, Che 7 makes it easier for developers to deliver value to their stakeholders and their customers. 

Not to be outdone, the next quarterly simultaneous release of the Eclipse IDE is expected this Wednesday, September 18. As one of the world’s most popular desktop development environments, the Eclipse IDE is downloaded over 2 million times per month, and is the critical development environment for more than 4 million active users. Be sure to download the 2019-09 version of the IDE here. 

Of course, all this activity is the result of the direct contribution of our community. So, congratulations and thank you to our dedicated, global community of thousands of developers, leading vendors across industries, and end user organizations. Your continued commitment and participation are what make all this possible.

And stay tuned, we’ll be making a series of announcements, releasing community-generated content, and sharing updates over the next few months. 

Meanwhile, Eclipse Che 7 will be showcased alongside Jakarta EE 8, MicroProfile, and GlassFish at booth #3228 at Code One this week.

by Thabang Mashologu at September 17, 2019 01:01 PM

Eclipse Night School

by Anonymous at September 17, 2019 01:12 AM

Come to Night School, and learn all about what the Foundation staff does to make your (Eclipse) life better!

We will talk, but then you will get a chance to ask, to comment, and to discuss. And there will be free beer!

Eclipse Night School is part of Community Evening on Tuesday, October 22 (19:30, Wilhelm-Krämer-Zimmer room). More details to follow, but here is a list of topics to be covered:

  • Web Development and Marketing at the Eclipse Foundation
  • Hosting 200+ Jenkins servers and not breaking a sweat
  • Running a Successful Open Source Project
  • The Eclipse Development Process for Committers
  • Say goodbye to Bugzilla!

by Anonymous at September 17, 2019 01:12 AM

Eclipse Proposes Vulnerability Assessment Tool

by Erik Costlow at September 14, 2019 05:12 AM

The Eclipse Foundation is evaluating a proposal to incorporate a Vulnerability Assessment Tool, that would help identify libraries with known security issues. The possible result would help inform developers when their application faces a downstream risk from using vulnerable components.

By Erik Costlow

by Erik Costlow at September 14, 2019 05:12 AM

Eclipse download increases by more than 100% in the last year

September 11, 2019 12:00 AM

Downloads have increased by more than 3.3 millions compared to last years release. The Eclipse Photon release was downloaded 2.8 million times. The Eclipse 2019-06 release was downloaded 6.1 millions times. Great news for the Eclipse IDE! That is more than 100% increase from June 2018 to the June 2019 release. While it is hard to speculate why this is happening we think that the increased stability and performance as well as modern solutions based on the language server for JavaScript and Rust have changed the perception of Eclipse.

September 11, 2019 12:00 AM

Keynote Lineup

by Anonymous at September 10, 2019 09:53 PM

Adding to this year's technical content are three keynote speakers of wide-ranging topics and styles. Meet them here, but get ready to engage with them at EclipseCon Europe!

Jan Leuridan, Siemens PLM Software

Comprehensive Digital Twin: An Enabler for Model Based System Engineering

Matt Rutkowski, IBM

Java in the Age of Serverless: The Path Forward

Mark Little, Red Hat

Kubernetes Native Java and Eclipse MicroProfile

by Anonymous at September 10, 2019 09:53 PM

Welcome to the Future of Cloud Native Java

by Mike Milinkovich at September 10, 2019 11:00 AM

Today, with the release of Jakarta EE 8, we’ve entered a new era in Java innovation.

Under an open, vendor-neutral process, a diverse community of the world’s leading Java organizations, hundreds of dedicated developers, and Eclipse Foundation staff have delivered the Jakarta EE 8 Full Platform, Web Profiles, and related TCKs, as well as Eclipse GlassFish 5.1 certified as a Jakarta EE 8 compatible implementation.

To say this a big deal is an understatement. With 18 different member organizations, over 160 new committers, 43 projects, and a codebase of over 61 million lines of code in 129 Git repositories, this was truly a massive undertaking — even by the Eclipse community’s standards. There are far too many people to thank individually here, so I’ll say many thanks to everyone in the Jakarta EE community who played a role in achieving this industry milestone.

Here are some of the reasons I’m so excited about this release.

For more than two decades, Java EE has been the platform of choice across industries for developing and running enterprise applications. According to IDC, 90 percent of Fortune 500 companies rely on Java for mission-critical workloads. Jakarta EE 8 gives software vendors, more than 10 million Java developers, and thousands of enterprises the foundation they need to migrate Java EE applications and workloads to a standards-based, vendor-neutral, open source enterprise Java stack.

As a result of the tireless efforts of the Jakarta EE Working Group’s Specification Committee, specification development follows the Jakarta EE Specification Process and Eclipse Development Process, which are open, community-driven successors to the Java Community Process (JCP) for Java EE. This makes for a fully open, collaborative approach to generating specifications, with every decision made by the community — collectively. Combined with open source TCKs and an open process of self-certification, Jakarta EE significantly lowers the barriers to entry and participation for independent implementations.

The Jakarta EE 8 specifications are fully compatible with Java EE 8 specifications and include the same APIs and Javadoc using the same programming model developers have been using for years. The Jakarta EE 8 TCKs are based on and fully compatible with Java EE 8 TCKs. That means enterprise customers will be able to migrate to Jakarta EE 8 without any changes to Java EE 8 applications.

In addition to GlassFish 5.1 (which you can download here), IBM’s Open Liberty server runtime has also been certified as a Jakarta EE 8 compatible implementation. All of the vendors in the Jakarta EE Working Group plan to certify that their Java EE 8 implementations are compatible with Jakarta EE 8.

 All of this represents an unprecedented opportunity for Java stakeholders to participate in advancing Jakarta EE to meet the modern enterprise’s need for cloud-based applications that resolve key business challenges. The community now has an open source baseline that enables the migration of proven Java technologies to a world of containers, microservices, Kubernetes, service mesh, and other cloud native technologies that have been adopted by enterprises over the last few years.

As part of the call to action, we’re actively seeking new members for the Jakarta EE Working Group. I encourage everyone to explore the benefits and advantages of membership. If Java is important to your business, and you want to ensure the innovation, growth, and sustainability of Jakarta EE within a well-governed, vendor-neutral ecosystem that benefits everyone, now is the time to get involved.

Also, if you’re interested in learning more about our community’s perspective on what cloud native Java is, why it matters so much to many enterprises, and where Jakarta EE technologies are headed, download our new free eBook, Fulfilling the Vision for Open Source, Cloud Native Java. Thank you to Adam Bien, Sebastian Daschner, Josh Juneau, Mark Little, and Reza Rahman for contributing their insights and expertise to the eBook.

Finally, if you’ll be at Oracle Code One at the Moscone Center in San Francisco next week, be sure to stop by booth #3228, where the Eclipse community will be showcasing Jakarta EE 8, GlassFish 5.1, Eclipse MicroProfile, Eclipse Che, and more of our portfolio of cloud native Java open source projects.


by Mike Milinkovich at September 10, 2019 11:00 AM

From building blocks to IoT solutions

by Jens Reimann at September 10, 2019 07:07 AM

Eclipse IoT

The Eclipse IoT ecosystem consists of around 40 different projects, ranging from embedded devices, to IoT gateways and up to cloud scale solutions. Many of those projects stand alone as “building blocks”, rather than ready to run solutions. And there is a good reason for that: you can take these building blocks, and incorporate them into your own solution, rather than adopting a complete, pre-built solution.

This approach however comes with a downside. Most people will understand the purpose of building blocks, like “Paho” (an MQTT protocol library) and “Milo” (an OPC UA protocol library) and can easily integrate them into their solution. But on the cloud side of things, building blocks become much more complex to integrate, and harder to understand.

Of course, the “getting started” experience is extremely important. You can simply download an Eclipse IDE package, tailored towards your context (Java, Modelling, Rust, …), and are up and running within minutes. We don’t want you to design your deployment descriptors first, and then let you figure out how to start up your distributed cluster. Otherwise “getting started” will become a week long task. And a rather frustrating one.

Getting started. Quickly!

Eclipse IoT building blocks

During the Eclipse IoT face-to-face meeting in Berlin, early this year, the Eclipse IoT working group discussed various ideas. How can we enable interested parties to get started, with as little effort as possible. And still, give you full control. Not only with a single component, which doesn’t provide much benefit on its own. But get you started with a complete solution, which solves actual IoT related problems.

The goal was simple. Take an IoT use case, which is easy to understand by IoT related people. And provide some form of deployment, which gets people up and running in less than 15 minutes. With as little as possible external requirements. At best, run everything on your local laptop. Still, create everything in a close-to-production style of deployment. Not something completely stripped down. But use a way of deployment, that you could actually use as a basis for extending it further.

Kubernetes & Helm

We quickly agreed on Kubernetes as the runtime platform, and Helm as the way to perform the actual deployments. With Kubernetes being available even on a local machine (using minikube on Linux, Windows and Mac) and being available, at the same time, in several enterprise ready environments, it seemed like an ideal choice. Helm charts seemed like an ideal choice as well. Helm designed directly for Kubernetes. And it also allows you to generate YAML files, from the Helm charts. So that the deployment only requires you to deploy a bunch of YAML files. Maintaining the charts, is still way easier than directly authoring YAML files.

Challenges, moving towards an IoT solution

A much tougher question was: how do we structure this, from a project perspective. During the meeting, it soon turned out, there would be two good initial candidates for “stacks” or “groups of projects”, which we would like to create.

It also turned out that we would need some “glue” components for a package like that. Even though it may only be a script here, or a “readme” file there. Some artifacts just don’t fit into either of those projects. And what about “in development” versions of the projects? How can you point people towards a stable deployment, only using a stable (released) group of projects, when scripts and readme’s are spread all over the place, in different branches.

A combination of “Hono, Ditto & Hawkbit” seemed like an ideal IoT solution to start with. People from various companies already work across those three projects, using them in combination for their own purpose. So, why not build on that?

But in addition to all those technical challenges, the governance of this effort is an aspect to consider. We did not want to exclude other Eclipse IoT projects, simply by starting out with “Hono, Ditto, and Hawkbit”. We only wanted to create “an” Eclipse IoT solution, and not “the” Eclipse IoT solution. The whole Eclipse IoT ecosystem is much too diverse, to force our initial idea on everyone else. So what if someone comes up with an additional group of Eclipse IoT projects? Or what if someone would like to add a new project to an existing deployment?

A home for everyone

Luckily, creating an Eclipse Foundation project solves all those issues. And the Eclipse Packaging project already proves that this approach works. We played with the idea, to create some kind of a “meta” project. Not a real project in the sense of having a huge code base. But more a project, which makes use of the Eclipse Foundations governance framework. Allowing multiple, even competing companies, to work upstream in a joint effort. And giving all the bits and pieces, which are specific to the integration of the projects, a dedicated home.

A home, not only for the package of “Hono, Ditto and Hawkbit”, but hopefully for other packages as well. If other projects would like to present their IoT solution, by combining multiple Eclipse IoT projects, this is their chance. You can easily become a contributor to this new project, and publish your scripts, documentation and walk-throughs, alongside the other packages.

Of course everything will be open source, licensed under the EPL. So go ahead and fork it, add your custom application on top of it. Or replace an existing component with something, you think is even better than what we put it. We want to enable you to deploy what we provide in a few minutes. Offer you an explanation, what to expect from it, and what this IoT solution can do for you. And encourage you to play around with it. And enable you to extend it, and build something bigger.

Let’s get started

EclipseCon Europe 2019

We created a new project proposal for the Eclipse IoT packages project. The project is currently in the community review phase. Once we pass the creation review, we will start publishing the content for the first package we have.

The Eclipse IoT working group will also meet at the IoT community day of EclipseCon Europe 2019. Our goal is to present an initial version of the initial package. Ready to run!

But even more important, we would like to continue our discussions around this effort. All contributions are welcome: code, documentation, additional packages … your ideas, thoughts, and feedback!

The post From building blocks to IoT solutions appeared first on ctron's blog.

by Jens Reimann at September 10, 2019 07:07 AM

Release 3.5

September 10, 2019 12:00 AM

New version 3.5 released.

Release of Type B


  • Select branch for Push
  • Select branch for Pull
  • Usage Statistics
  • Import an arbitrary file into a workspace folder
  • Generic support for Statusbar
  • Programmatic Custom Datasources Support
  • Destinations API v4
  • jsonpath and alphanumeric APIs v4


  • Reset perspective option in Dirigible
  • Validation of the Listener handler to be done on Start
  • Restart the Listener after modification
  • Require confirmation from user on deletion of files, folders or projects
  • Problem with setTimestamp, setTime and setDate of Statement
  • Response API println and print don’t work with UTF-8 characters
  • Security - Missing isInRole() method
  • Updating Date is not working on HANA database
  • Updating Boolean is not working on HANA database
  • Fiori theme fixes and improvements
  • Minor fixes


  • 4000+ Downloads
  • 10K+ Docker Pulls
  • 5.4K+ Trial Users
  • 59K+ Sessions
  • 179 Countries
  • 354 Repositories in DirigibleLabs



September 10, 2019 12:00 AM

Update for Jakarta EE community: September 2019

by Tanja Obradovic at September 09, 2019 03:12 PM

We hope you’re enjoying the Jakarta EE monthly email update, which seeks to highlight news from various committee meetings related to this platform. There’s a lot happening in the Jakarta EE ecosystem so if you want to get richer insight into the work that has been invested in Jakarta EE so far and get involved in shaping the future of Cloud Native Java, read on. 

Without further ado, let’s have a look at what happened in August: 

EclipseCon Europe 2019: Register for Community Day 

We’re gearing up for EclipseCon Europe 2019! If you’ve already booked your ticket, make sure to sign up for Community Day happening on October 21; this day is jam-packed with peer-to-peer interaction and community-organized meetings that are ideal for Eclipse Working Groups, Eclipse projects, and similar groups that form the Eclipse community. As always, Community Day is accompanied by an equally interesting Community Evening, where like-minded attendees can share ideas, experiences and have fun! 

That said, in order to make this event a success, we need your help. What would you like Community Day & Evening to be all about? Check out this wiki give us your suggestions and let us know if you plan to attend by signing up at the bottom of the wiki. Also, make sure to go over what we did last year. And don’t forget to register for Community Day and Evening! 

EclipseCon Europe will take place in Ludwigsburg, Germany on October 21 - 24, 2019. 

JakartaOne Livestream: There’s still time to register!

JakartaOne Livestream, taking place on September 10, is the fall virtual conference spanning multiple time zones. Plus, the date coincides with the highly anticipated Jakarta EE 8 release so make sure to save the date; you’re in for a treat! 

We hope you’ll attend this all-day virtual conference as it unfolds; this way, you get the chance to interact with renowned speakers, participate in interesting interactions and have all your questions answered during the interactive sessions. More than 500 people have already signed up to participate in JakartaOne Livestream so register now to secure your spot! 

Once you’ve registered, you will have the opportunity to post questions and/or comments for the talks you’re interested in.  We encourage all participants to make the most out of this virtual event by sharing your questions and chiming in with your suggestions/comments! 

No matter if you’re a developer or a technical business leader, this virtual conference promises to satisfy your thirst for knowledge with a balance of technical talks, user experiences, use cases and more. Check out the schedule here

Jakarta EE 8 release

The moment we've all been waiting for is almost upon us. The expected due date of Jakarta EE 8 is September 10 and we’re in the final stages of preparation for specifications. Eclipse GlassFish 5.1, as well as Open Liberty, open source Jakarta EE compatible implementations, are expected to be released on the same day, and other compatible implementations are expected to follow suit. 

Keep an eye out for the Jakarta EE 8 page, which will include all the necessary information and updates related to the Jakarta EE 8 release, including links to specifications, compatible products, Eclipse Cloud Native Java eBook and more.  

If you’d like to learn more about cloud native Java and Jakarta EE, the Eclipse Foundation will be at Oracle Code One, so come armed with questions. Stop by our booth -number 3228- to say hi, ask questions or chat with our experts. Here’s who you can expect to see in our booth for Oracle Code One:

  • A lot of community participation at the boot, after all this is an open source community driven project!

  • Pods dedicated to Jakarta EE, MicroProfile and Eclipse Che

  • A lot of information and discussion about the Jakarta EE 8 release and related Compatible Implementations 

Jakarta EE Community Update: August video call

The most recent Jakarta EE Community Update meeting took place on August 27; the conversation included topics such as the progress and latest status of the Jakarta EE 8 release as well as details about JakartaOne Livestream and EclipseCon Europe 2019.   

The materials used in the Jakarta EE community update meeting are available here and the recorded Zoom video conversation can be found here.  

Fulfilling the Vision for Open Source, Cloud Native Java: Coming soon! 

What does cloud native Java really mean to developers? What does the cloud native Java future look like? Where is Jakarta EE headed? Which technologies should be part of your toolkit for developing cloud native Java applications? 

All these questions (and more!) will be answered soon; we’re developing a downloadable eBook called Fulfilling the Vision for Open Source, Cloud Native Java on the community's definition and vision for cloud native Java, which will become available shortly before Jakarta EE 8 is released. Stay tuned!

Cloud Native Java & Jakarta EE presence at events and conferences: August overview 

We’d like to give kudos to Otávio Santana for his hard work this past summer on his 11+ conference session tour on “Jakarta on the Cloud America Latina 2019”. It’s great to see the success of your sessions and we are happy to promote your community participation. 

Informally, the OSS repo being used for the Community, including the Eclipse Foundation team, to provide feedback is via this repo, plus the Jakarta Community forum. Anyone who has Java EE & Jakarta sessions coming up is welcome to submit them via issues to broaden the message and not make it exclusive of the committee access. 

Links you may want to bookmark!

Thank you for your interest in Jakarta EE. Help steer Jakarta EE toward its exciting future by subscribing to the mailing list and by joining the Jakarta EE Working Group. Don’t forget to follow us on Twitter to get the latest news and updates!

To learn more about the collaborative efforts to build tomorrow’s enterprise Java platform for the cloud, check out the Jakarta Blogs and participate in the monthly Jakarta Tech Talks. Don’t forget to subscribe to the Eclipse newsletter!  

The Jakarta EE community promises to be a very active one, especially given the various channels that can be used to stay up-to-date with all the latest and greatest. Tanja Obradovic’s blog offers a sneak peek at the community engagement plan, which includes

Note: If you’d like to learn more about Jakarta EE-related plans and get involved in shaping the future of cloud native Java and see when is the next Jakarta Tech Talk, please bookmark the Jakarta EE Community Calendar

by Tanja Obradovic at September 09, 2019 03:12 PM

The Rising Adoption of Capella

by Cédric Brun ( at September 04, 2019 12:00 AM

Witnessing an OSS technology getting together with a wide group of users is something I find exhilarating, I have experienced it with Acceleo, EMF Compare and Eclipse Sirius along the years, each time in different contexts and at different scales but discovering what is being done by others with a technology is always a source of excitement to me.

Capella was contributed by Thales to the Eclipse communities a few years ago already and fueled by the growing need to design Systems in a better way, by the interest in Model Based System Engineering and the qualities of the product in itself we can clearly see an acceleration in the last few months.

If you are wondering what is Capella and what it’s used for, here is a 2-minute video we prepared for you:

Worldwide awareness of this solution grows and adoption rises, organizations from Europe, North America and Asia are now using Capella and experiencing the benefits of using a tool which implements a method (coined “Arcadia”) and not only a language.

Capella Forum Activity

Looking at the numbers, just for this summer : more than 1200 downloads each month, a forum actvity which has been growing with a nice looking curve and monthly stats on YouTube reaching more than 2000 views: considering the size of the target audience this is a significant acceleration and that is without counting the deployment of System Modeling Workbench provided by Siemens which includes the technology.

Adopters not only use it but speak about it and as with any other tool having an opportunity to understanding how others are using it is highly valuable.

Rolls Royce, ArianeGroup or the Singapore University: they all have shared valuable information through the recent webinars :

More are coming and many already available through the Resources Page! BTW we can’t always get the authorization to keep them available online so your safest option is to register and attend.

Munich (Germany)

We also make sure to setup « in Real Life » opportunities to discuss Capella and MBSE. Occasions to talk with the team behind Capella and the experts arounds the world. Next up is Capella Day Munich 2019 in a couple of weeks (the 16th of September) organized by Thales and Obeo in conjunction with the Models Conference 2019. Here is a glimpse of the program :

The agenda is filled with general presentations, feedback by industrial users about their Capella deployment or specific add-ons/integration.

The program of Capella Day Munich 2019

You might want to hurry as we are almost sold out and such occasions are pretty unique!

I sincerely hope you’ll enjoy it, we are working hard to make it a success :-), if you can’t make it this time then know there are more occasions to come: AOSEC in Bangalore, EclipseCon in Germany (again!) where there might be a workshop focused on “MBSE at Eclipse” (Please add your name and interest on the corresponding wiki page )

The Rising Adoption of Capella was originally published by Cédric Brun at CEO @ Obeo on September 04, 2019.

by Cédric Brun ( at September 04, 2019 12:00 AM

Time for Change

by Doug Schaefer at September 03, 2019 02:56 PM

First, let me get straight to the point. I have left BlackBerry/QNX and will be starting a new job in Ottawa next week. It’s a great opportunity to work on something new for a great company with a bunch of former colleagues I admire. As much as I’m looking forward to that much needed change, it sadly will take me away from the Eclipse community. This message is a goodbye and thank you.

Thinking back all the way to the beginning, I’m quickly overwhelmed by how many great people I have had the opportunity to work with thanks to the Eclipse CDT project. At the very beginning was Sky Matthews and John Prokopenko who let me weasel my way on as Rational’s technical lead on the project just as it was starting out in 2002 also at a time when I needed a change. Of course, I had a great team of developers at Rational with me that made it fun and easy. Not to mention the original team at QNX who were welcoming and made it easy to get involved. I have a special mention for Sebastien Marineau, CDT’s first project lead, who let me take a leadership role on the project and eventually hired me on at QNX to take over.

Then there was the early years on the CDT where we made our mark. Those early CDT Summits were so fun and really helped built up a team atmosphere. We had about a dozen companies sending contributors, a few of them competitors in the spirit of co-opetition, and we made it work. Then over the years we started getting independent contributors who just did it for the passion of building great C++ tooling they wanted to use themselves. It’s been a great mix and I am so lucky and proud to have been a part of it.

And of course, it was all topped off with our yearly EclipseCons. I am proud to have attended every one of the EclipseCon North America ones and was able to attend quite a few of the EclipseCon Europes in Germany. I have to thank Anne and Mike and Ralph and Wayne and Sharon and Perri and Donald and Ian and Lynn and all the Eclipse Foundation staff past and present for making me feel a part of the family. I always looked forward to the EclipseCon Express flights out of and return to Ottawa with many of them.

My fellow attendees at these conferences were amazing, from the first one at Disneyland where we had an overflow crowd at the CDT BOF and where I gave my first of many CDT talks, to all the friends I met at the bar or ran into at sessions, many of whom had nothing to do with CDT but made me feel so much a part of the bigger community. I will never forget the late nights in the bars chatting with friends like Michael Scharf and Ian Bull and Eric Cloninger and Gilles and Adrian and Jonah and Tom and so many others. As it turns out, last year in Ludwigsburg was a perfect finale where we had such a great time at the Nestor on Wednesday night. I will never forget you all.

I’m incredibly proud of what we built for the CDT. It still has the best indexer in the business, thanks to the parser we built back at Rational and the database I built at QNX and then with so many hands continually making it better and adjusting to the now ever changing C++ language spec. The Launch Bar achieved what I wanted by simplifying the Eclipse launch experience. CDT’s new Core Build fits naturally with the Launch Bar and makes it much simpler to integrate external build systems like CMake. And we have just started a GDB debug adapter using the debug adapter protocol which will pave the way to simplify integrating debuggers with the CDT.

The current set of active committers on the CDT have lately been pulling almost all the weight evolving it and getting releases out the door. Their great work has made my transition easier and will keep the CDT rolling along for years to come. And hopefully vendors will come back too and help provide funding for all this activity. We have an action plan to transition the project lead role. Follow the cdt-dev mailing list to find out more.

It’s sad to leave and the memories and friendships will be forever. I will keep my cdtdoug personal gmail account as a reminder of where I came from. But my new role will give me some much needed energy to keep things going for the next decade. I once questioned why you hardly see any retired engineers helping with open source projects or sharing their passion with the next generation. I promise you this, you will see me again.

Take care, and thank you.

by Doug Schaefer at September 03, 2019 02:56 PM

Xtext 2.19 Release – builds on Eclipse’s new infrastructure JIRO

by Karsten Thoms ( at September 03, 2019 07:27 AM

The Xtext team has released version 2.19.0 of Eclipse Xtext & Xtend. The current version is mainly a maintenance release. After working hard on some new features in the past releases, it was time for summer vacation during the current release period and for some focus on build engineering tasks. Still over 350 pull requests made it into the short release period.


Eclipse’s new build infrastructure JIRO

The Eclipse Foundation’s build engineers worked on a new build infrastructure called JIRO (Jenkins Instances Running on OpenShift). The Xtext project joined early the efforts on preparing a migration to the new infrastructure. However, now it was time and the Eclipse Foundation asked to finally shut down the old build server and to switch over to the new infrastructure. While we were already done with the main build jobs, there were still quite some supportive build jobs for release engineering that had to be migrated.

Luckily, the itemis Xtext team could acquire Nico Prediger from the itemis DevOps staff to support the efforts on build engineering tasks. With his support, we could finalize the work and finally replace the old Jenkins instance.

As a result, Xtext builds fine now on its new JIRO instance at and was released the first time on the new infra.

Keeping the software stack up-to-date

Xtext builds upon a quite huge software stack, and several components are released within each release period. We try to keep them all on the latest state as far as we can. Of course, for each used component we have to test the compatibility of each upgrade.

The most notable upgrades this time are Guava and Gradle:

The Guava version 21.0 that we used before had a security problem that was issued as CVE-2018-10237. This forced Xtext as well as other dependent Eclipse projects to upgrade to a recent version of Guava. For the Eclipse 2019-09 simultaneous release, the delivered Guava version is now 27.1.0. All builds descriptors, wizards, and projects have been updated to use Guava 27.1.0 now.

The Guava upgrade also affected the MWE project, which employed the upgrade with its recent release. As a consequence, Xtext upgraded to MWE 2.11.

Xtext has been updated to use Gradle 5.5 now. While Gradle 6 is not official yet, Xtext has already been prepared for it. We closely followed the planned changes and revisited all relevant sources to ensure compatibility with Gradle’s next major versions. We expect that Xtext finally upgrades to Gradle 6 shortly after its release.


With the rise of the Language Server Protocol (LSP) integration of Xtext-based languages into other IDEs and editors, it is often preferred to work through language servers. Xtext is integrating the latest LSP4J version 0.8.0 und thus the current status of the LSP.

When it comes to language support in web-based editors, Xtext offers a second approach called Xtext Web. The software components that Xtext Web is based on have been upgraded to their latest state. Also, the examples have been polished again with this version.

To get a better feeling, we have put the Xtext Web examples online now, so you don’t have to download and build them locally. Try the Xtext Web integration with the various supported editors Ace, CodeMirror, and Orion here:

What’s your wish for future Xtext versions?

We will continue to implement exciting features and ensure that Xtext will be compatible with the latest and greatest of all that we use. While we focus the development on the needs of our customers, you may have ideas how to make Xtext even better. Please tell us! We won’t bite you (and we can’t do this through the wire anyway)!

by Karsten Thoms ( at September 03, 2019 07:27 AM

OSGi Remote Services with Apache Dubbo

by Scott Lewis ( at August 31, 2019 05:37 PM

ECF's implementation of OSGi R7 Remote Services allows for replacing the underlying distribution system (repsonsible for the object serialization, transport, and other things). 

This makes it relatively easy to replace one kind of distribution (e.g. Jersey, ActiveMQ) with other/new distribution systems. 

Apache Dubbo has recently been contributed to Apache, and we've created a distribution provider based upon Apache Dubbo.

Here's a list of open ECF Remote Service distribution providers.   If you would like Remote Services support for a particular transport, or you've created your own distribution (or discovery) based upon some other transport and wish to make it available to others please let us know.

by Scott Lewis ( at August 31, 2019 05:37 PM

Eclipse Module on F30 Addendum

by Mat Booth at August 30, 2019 11:30 AM

Additional information about installing the Eclipse IDE module on F30.

by Mat Booth at August 30, 2019 11:30 AM

Eclipse Vert.x for Scala next steps

by codepitbull at August 30, 2019 12:00 AM

Scala for Eclipse Vert.x: The next steps


  • No Scala 2.13 in Eclipse Vert.x 3.x due to increased support burden
  • New value classes based approach for Vert.x 4


It’s been more than two years since the inception of vert-lang-scala to the Vert.x ecosystem. And almost as long since I wrote my first blog post about it.

A lot has happened since March 2017:

  • vertx-lang-scala kept up with new versions of Scala
  • all Vert.x-modules are supported (35 so far)
  • a Giter8 based template was added for easily bootstrapping a Vert.x-Scala-project
  • Bugs were squashed

And most recently we received a great contribution by Nikolaj Leischner who was kind enough to port the techempowered benchmark to vert-lang-scala. Which will be part of the next steps.

The numbers produced by this benchmark were very promising and and additional motivation to move to the next phase of Scala support for Vert.x.

Old idea

Before getting to the new ideas I want to take a look at the “old” one.

The current version of vert-lang-scala is based around the idea of wrapping the Vert.x-API with a dedicated Scala-layer. That layer is created using a Freemarker-based code generator. I took this idea from the first try by Tim Fox for building that support.

Wrapping the existing Java-API was rather painful but gave me great flexibility to create an idiomatic Scala-API.

But an approach like that comes with a price:

  • There are a lot of intermediate objects being created.
  • Many unneccessary conversions between Java/Scala types

Both increased memory consumption and garbage collection activity quite a bit and has been bugging me from the beginning.

New idea

With Vert.x 4 approaching I was finally able to invest time into the rework I had wanted to do for quite a while.

The core idea is to replace the current wrapping based approach with something more lightweight but native to the Scala-world.

And that’s where value classes come in.

Value classes allow the extension of existing classes with additional methods. They make it easy to control when methods become visible and do that with a minimum of overhead. To be precise: A wrapping class is normally ever only instantiated once.

A good example is the addition of methods for wrapping the Vert.x approach of Promises with Scala-Futures. Each method returning a Vert.x-Promise needs to receive an alternative version which returns a Scala-Future.

In Vert.x 3 I achieved that by adding methods to the wrapper and giving them a distinct name. A method called listen returning a Promise would receive a companion called listenFuture in the Scala layer.

Let’s look at how this looks in the new approach:

package io.vertx.scala
package object core{
   implicit class HttpServerScala(val asJava: io.vertx.core.http.HttpServer) extends AnyVal {
      def listenFuture(port: java.lang.Integer): scala.concurrent.Future[io.vertx.core.http.HttpServer] = {..}

The code above does the following things:

  • It creates a package object for io.vertx.scala.core
  • it adds an implict class HttpServerScala to wrpa HttpServer
  • it adds a listenFuture method

Using this method in code looks like this:

package io.vertx.scala.demo

import io.vertx.lang.scala.VertxExecutionContext
import io.vertx.scala.core._

import scala.util.{Failure, Success}

object Main {
  def main(args: Array[String]): Unit = {
    val vertx = Vertx.vertx()
    implicit val ec = VertxExecutionContext(vertx.getOrCreateContext())
      .requestHandler(r => {
      .onComplete {
        case Success(_) => println("Started")
        case Failure(exception) => println("Failure")

Importing the package object using import io.vertx.scala.core._ brings the extension method into scope and makes them available on all instances of HttpServer. In the example above createHttpServer() return such an instance and we can now use the idiomatic Scala way of handling a Future.

Even more

Extending classes with Future-methods is only one of the new things to come. On top of that the support for DataObjects will be considerably improved, both through extending them and by providing type aliases.

I also switched from doing all conversions for collections automatically to handing the control back to the user. Something which gets even more important for Scala 2.13 and the new collection API.

The downside

The clear downside of this approach is that the Java-methods will stay visible since the java-classes won’t be wrapped but extended. This might lead to some confusion but I am pretty sure the benefits outweight this downside.

The bigger change will be the removal of automatic vonversion between Scala types (Long/Int/String and Collections) and their Java counterparts. I spent considerable time trying to tune that part in the current version bbut always ended up hitting some edgecase. For now I’ve decided to have the user pick the right time to convert.

I might still add this feature in a later version if user feedback points into that direction.

When will I get it?

First for the good news: There is already a branch with a full implementation.

The bad news: It will break until Vert.x 4.0 is finally released.

Vert.x 4 is in active development with most APIs already finalized but breaking changes still happen. So use at your own risk!

What about Scala 2.13?

Scala 2.13 has been released recently which prompted questions from the community about when it will be supported by Vert.x.

I haven’t done a good job providing the results of our internal discussions on that topic to the community. So here we go:

  • Vert.x 3 will stay on 2.12 for the following reasons:
    • Both are still actively supported
    • Scala ecosystems takes some time to do the switch to 2.13
    • We simply don’t have the capacity to support both versions AND the upcoming new version
  • Vert.x 4 will receive 2.13 support
    • Scala ecosystem will have moved closer to 2.13 adoption when Vert.x 4 comes out

For the adventure seaker

I actually did a port of vertx-lang-scala 3.8 to Scala 2.13 and you can grab the work in this branch.

Don’t expect ANY support for this branch. This was only an experiment to see how much I had to change for initial 2.13 support.


Vert.x 4 will be an evolutionary step for vertx-lang-scala. Value classes promise to reduce both complexity and allocation rate, two things which have been bugging me quite a bit with the current approach.

I am eager to hear from you all what you think about this new direction.

by codepitbull at August 30, 2019 12:00 AM

Eclipse Collections 10.0 Released

by Donald Raab at August 29, 2019 11:57 PM

The features you want, with the collections you need.

Thank you to the contributors

Eclipse Collections 9.2 was released in May 2018. The 9.x releases were extremely feature rich and had many contributions from the community. The 10.0 release is even more so. There were 18 contributors in the 10.0 release. This is outstanding! Thank you so much to all of the contributors who donated their valuable time to making Eclipse Collections more feature rich and even higher quality. Your efforts are truly appreciated.

Too many features for one blog

There are so many features included in Eclipse Collections 10.0, that it is going to take me a bit longer to write good examples leveraging all of them. So I have decided to break this release blog into a few parts. This part will purely be a summary.

Update: Detailed Feature Blogs

Part 1 — Covers Features 1–10

Part 2 — Covers Features 11–20

Part 3 — Covers Features 21–26

My Top 10 List of Features

The Feature Summary

  1. Specialized Interfaces for MultiReaderList/Bag/Set
  2. Implement Stream for Primitive Lists
  3. Implement toMap with target Map
  4. Implement MutableMapIterable.removeAllKeys
  5. Implement RichIterable.toBiMap
  6. Implement Multimap.collectKeyMultiValues
  7. Implement fromStream(Stream) on collection factories
  8. Implement LazyIterate.cartesianProduct
  9. Add updateValues to primitive maps
  10. Implement MutableMultimap.getIfAbsentPutAll
  11. Implement Bag.collectWithOccurrences
  12. Add reduce and reduceIfEmpty for primitive iterables
  13. Add <type1><type2>To<type1>Function for primitives
  14. Add ofInitialCapacity to primitive maps
  15. Implement countByEach on RichIterable
  16. Implement UnifiedSetWithHashingStrategy.addOrReplace
  17. Implement UnmodifiableMutableOrderedMap
  18. Implement withAllKeyValues on mutable primitive maps.
  19. Add ability to create PrimitivePrimitive/PrimitiveObject/ObjectPrimitiveMap from Iterable
  20. Implement ofInitialCapacity and withInitialCapacity in HashingStrategySets
  21. Implement getAny on RichIterable
  22. Revamp and standardize resize/rehash for all primitive hash structures
  23. Implement factory methods to convert Iterable<BoxedPrimitive> to PrimitiveStack/Bag/List/Set
  24. Implement ImmutableSortedBagMultimapFactory in Multimaps
  25. Implement a Map factory method that takes a Map parameter.
  26. Wildcard type in MultableMultimap.putAllPairs & add methods

Check out the latest JavaDoc for the new features.

Other Improvements

  1. Improved Test Coverage
  2. Many build improvements
  3. Remove duplicate code
  4. Removed some deprecated classes
  5. Improved generics
  6. Some new benchmark tests
  7. And much more!

Thank you

From all the contributors and committers… thank you for using Eclipse Collections. We hope you enjoy all of the new features and improvements in the 10.0 release.

I’ll be publishing detailed examples for the new features in the 10.0 release in a few blogs. Stay tuned!

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.

Eclipse Collections 10.0 Released was originally published in Oracle Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Donald Raab at August 29, 2019 11:57 PM

Redux App Development and Testing in N4JS (Chess Game Part 2)

by n4js dev ( at August 29, 2019 04:04 PM

In large applications, Redux - an implementation of Flux architecture created by Facebook - is often used to organise application code by using a strict data flow in one direction only. Redux is UI agnostic, and can be used in conjunction with any UI library. As a continuation of our chess game tutorial with React, we show how to extract the entire program state out of React components, store it with Redux, and test it with N4JS. The full tutorial is available at and the sources can be found at

The first part of the chess game tutorial discussed how to develop a chess game app with React and JSX in N4JS. We have stored the program state - which for instance contains information about the locations of all chess pieces - in the state of the React components directly. As applications become larger, however, the mix of program state and UI makes the application hard to comprehend and difficult to test. To address these issues, we extract the program state from the UI components in the second part of the tutorial.

When using React with Redux, we store the application state in Redux store instead of the state of React components. As a result, React components become stateless UI elements and simply render the UI using the data retrieved from the Redux store. In a Redux architecture, data flows strictly in one direction. The diagram below graphically depicts the action/data flow in a React/Redux app.

Strict data flow of flux architecture application

The action/data flow in the diagram can be roughly understood as follows:
  • When a user interaction is triggered on the React component (e.g. button clicked, text field edited etc.), an action is created. The action describes the changes needed to be updated in the application state. For instance, when a text field is edited, the action created may contain the new string of the text field.
  • Then the action is dispatched to the Redux store whereby the Redux store stores the application state, usually as a hierarchical tree of state.
  • The reducers take the action and the current application state and create an updated application state.
  • If the changes in the application state are to a certain React component, they are forwarded into the component in form of props. The change in props causes the component to re-render.

In the second part of the tutorial we further elaborate on the interaction of React and Redux and migrate the original chess non-Redux app. The tutorial explains the role of the reducer, and how the game state is stored and maintained in the Redux store. Based on storing the game using Redux, the tutorial shows how to test the game application with the N4JS test library Mangelhaft, by for instance checking that valid move destination squares are updated after a chess piece was selected.

Note that the way of testing the game logics is completely UI-agnostic and no React components are involved at all. This is thanks to the decoupling of game logics from UI with the help of Redux.

by Minh Quang Tran

by n4js dev ( at August 29, 2019 04:04 PM

And Now for Something Completely Different

by Ed Merks ( at August 29, 2019 09:23 AM

It's been 5 years since I last blogged, so I had to delete 500 SPAM posts when getting started again.  Much has happened over the past years, some of them not so great. When you start to get old like me, you must deal with the older generation gradually passing on and health problems, such as coronary re-plumbing, can become an ugly fact of life.

I've been working with itemis for the past 11 years, but that now draws to a close.  I wish to thank them for their generous support over all these years.  Many of you might thank them as well because much of what I've contributed is thanks to their funding.  Though admittedly I have the nasty habit of working like a maniac, beyond any reasonable number of working hours, regardless of whether or not there is financial reward.  Cool things are just so compelling. But the worst habit then is not bothering to document or advertise all these cool new features as they become available, but rather to dive into the next obsession because somehow that's more compelling.  Compulsion is a bit of a Merks' family trait, e.g., my sister has more than 20 dogs, though it's easy to lose count...

In any case, most of my obsession over the last year has been related to working with Airbus.  I don't normally talk about my customers, but given they were gracious enough to allow me to demo at last year's EclipseCon the software being developed at Airbus, it's common knowledge anyway.  My goodness but that was a creative and cool project! Unfortunately that too has, as is the case for all good things, come to an end.

I immediately dove into generating a quality report for the Eclipse SimRel p2 repository; there's no rest for the wicked nor for the compelled.  I used EMF's Java Emitter Templates (JET) for implementing that, just as I did for generating the full site information for  EMF's Update Sites  as part of migrating the build to Maven/Tycho.

Speaking of which, did you know that you can make it trivially easy for your contributors to set up a development environment? Just have a look at EMF' build page.  Also, did you know that there exists such a thing for the complete Eclipse Platform SDK as well? Of course not, because I never bothered to tell you!

What's really supergeil (yes, I live in Germany and speak fluent Denglish) about the installing an environment with the full Platform SDK, or some subset there of, is that you can easily see all the Git history of each source file, so you can see what exactly has changed and evolved.  Also, when developing new applications, you can easily search for how the Platform implements those things; then you can snarf and barf out your own solutions, with all due respect for the EPL of course.  You can even find out all the places that a constant is actually used; you cannot do that against binaries because constants get in-lined.  Also, if you see some label in the IDE, you can search for where it comes from, some *.properties file somewhere no doubt, and then you will know the name of that property and can easily find where that's defined and how that's used in the code.  You might even contribute fixes via Gerrit commits!

But I digress.  I was using JET to generate a nice helpful web page with information about all the problems in the SimRel repo, or in any arbitrary repo actually, i.e., invalid licenses, unsigned content, missing pack200 files, duplicate bundles, inappropriate providers, and so on. But then I got frustrated that JET templates eventually get really hard to read, especially as they become more complicated.  Then, when you need it the most, all the nice features of JDT are missing while editing the scriplets and expressions in that template. So as I am wont to do, I digressed further and spent the better part of the last two months working on a rich editor for JET.  I'm sorry (not!) that I had to violate a few API rules to do so, but alas, API rights activists is a topic for another blog because that's a long digression.  The good thing is that the JET editor is finished now; it will be in 2019-09's M3.  Here's a sneak preview:

Yes, that's content assist, just is if were in a real Java editor! Not only that, this time I wrote documentation for it in EMF's doc bundle. And, to top that off with icing, this time I blog about it.  Perhaps only three people in the world will ever use it, but I am one of those three people and I love it and I need it even for working with EMF's code generation templates too. So now I can pop this off my digression stack and go back to generating that p2 repo quality report.  I've been doing that for the past week, and it's almost ready for prime-time.

But then at this point, I must ask myself, where is the financial gain in all this?  My local neighborhood fox, I've named him Fergus,  might be trying to tell me something.

Perhaps you should be a little more sly.  Perhaps the endless free goodness too must come to an end...

by Ed Merks ( at August 29, 2019 09:23 AM

Eclipse Ditto now supports OpenID Connect

August 28, 2019 04:00 AM

Eclipse Ditto now supports all OAuth 2.0 providers which implement OpenID Connect out-of-the-box. You can find a list of certified providers at OpenID Connect - Certified OpenID Provider Servers and Services.

With this post, we want to give an example of this new feature using the open source provider ORY Hydra. Follow their installation guide for a docker based setup on your development machine.


Download the self-signed certificate form the ORY Hydra server: https://localhost:9000/.well-known/openid-configuration

Use the downloaded certificate for the akka-http ssl configuration.

ssl-config {
  trustManager = {
    stores = [
      { type = "PEM", path = "/path/to/cert/globalsign.crt" }

The authentication provider must be added to the ditto-gateway configuration.

ditto.gateway.authentication {
    oauth {
      openid-connect-issuers = {
        ory = "https://localhost:9000/"

The configured subject-issuer will be used to prefix the value of the “sub” claim, e.g.

  "subjects": {
    "": {
    "type": "generated"

Authenticate Ditto API

Create an OAuth client with hydra to be able to create ID Tokens.

docker run --rm -it \
  -e HYDRA_ADMIN_URL=https://ory-hydra-example--hydra:4445 \
  --network hydraguide \
  oryd/hydra:v1.0.0 \
  clients create --skip-tls-verify \
    --id eclipse-ditto \
    --secret some-secret \
    --grant-types authorization_code,refresh_token,client_credentials,implicit \
    --response-types token,code,id_token \
    --scope openid,offline \

Use the client to generate an ID Token.

docker run --rm -it \
  --network hydraguide \
  -p 9010:9010 \
  oryd/hydra:v1.0.0 \
  token user --skip-tls-verify \
    --port 9010 \
    --auth-url https://localhost:9000/oauth2/auth \
    --token-url https://ory-hydra-example--hydra:4444/oauth2/token \
    --client-id eclipse-ditto \
    --client-secret some-secret \
    --scope openid

After that perform the OAuth 2.0 Authorize Code Flow by opening the link, as prompted, in your browser, and follow the steps shown there.

Use the generated token to authenticate Ditto API.

curl -X POST \
  http://localhost:8080/api/2/things \
  -H 'Authorization: Bearer <JWT>' \
  -H 'Content-Type: application/json' \
  -d '{}'


The Eclipse Ditto team

August 28, 2019 04:00 AM

Eclipse Vert.x 4 milestone 2 released!

by vietj at August 26, 2019 12:00 AM

We are extremely pleased to announce the second 4.0 milestone release of Eclipse Vert.x .

Vert.x 4 is the evolution of the Vert.x 3.x series that will bring key features to Vert.x.

This release aims to provide a reliable distribution of the current development of Vert.x 4 for people that want to try it and provide feedback.


Vert.x 4 extends the 3.x callback asynchronous model to a future/callback hybrid model.

public interface NetClient {

  // Since 3.0
  void connect(int port, String host, Handler> handler);

  // New in 4.0
  Future connect(int port, String host);

The first milestone, only covered Vert.x Core, this second milestone has made significant progress with the futurisation of the following stack modules:

  • vertx-auth
  • vertx-web
  • vertx-mqtt
  • vertx-cassandra-client
  • vertx-redis-client
  • vertx-kakfa-client
  • vertx-amqp-client


Instrumenting asynchronous application for distributed tracing is quite challenging because most tracing libraries rely on thread local storage. While it works reasonnably well in a blocking application, this does not work for an asynchronous application.

This supposes that the application control flow matters (i.e threads) although what really matters is the application request flow (e.g the incoming HTTP request).

We improved Vert.x 4 to reify the request flow, making it possible to integrate popular tracing tools such as Zipkin or Opentracing. Vert.x performance is legendary and we made sure that this does not have any overhead out of the box (disabled).

We provide support for these two popular libraries under the Vert.x Tracing umbrella.

Other changes

  • Groovy has been simplified in Vert.x 4 to remove code generation that was not really needed in practice
  • The original Redis client deprecated in 3.7 has been removed replaced by the new Redis client
  • The following components have reached their end of life and have been pruned
    • MySQL / PostgreSQL async client replaced by the Vert.x SQL Client (since 3.8)
    • AMQP bridge replaced by the Vert.x AMQP Client (since 3.7)

Ramping up to Vert.x 4

Instead of developing all new features exclusively in Vert.x 4, we introduce some of these features in the 3.x branch so the community can benefit from them. The Vert.x 4 development focus on more fundamental changes that cannot be done in the 3.x series.


This is the first milestone of Vert.x 4, we aim to release Vert.x 4 by the end of this year and you can of course expect more milestones to outline the progress of the effort.


The deprecations and breaking changes can be found on the wiki.

For this release there are no Docker images.,

The release artifacts have been deployed to Maven Central and you can get the distribution on Maven Central.

You can bootstrap a Vert.x 4.0.0-milestone2 project using

The documentation has been deployed on this preview web-site

That’s it! Happy coding and see you soon on our user or dev channels.

by vietj at August 26, 2019 12:00 AM

Eclipse is Now a Module on Fedora 30

by Mat Booth at August 21, 2019 01:30 PM

How to install the Eclipse IDE module on Fedora 30!

by Mat Booth at August 21, 2019 01:30 PM

Modeling Symposium @ EclipseCon Europe 2019

by Jonas Helming and Maximilian Koegel at August 20, 2019 08:58 AM

We are happy to announce that Ed, Philip and Jonas are organizing the Modeling Symposium for the EclipseCon Europe 2019 in...

The post Modeling Symposium @ EclipseCon Europe 2019 appeared first on EclipseSource.

by Jonas Helming and Maximilian Koegel at August 20, 2019 08:58 AM

GSoC 2019 Summary: Dart support for the Eclipse IDE

August 19, 2019 12:00 AM

Summary of my Summer of Code 2019

This post is a summary of my Summer of Code 2019. My project was to bring Dart development support to the Eclipse IDE. To do so I created a plugin that consumes the Dart analysis server using LSP4E. It also provides syntax highlighting using TM4E and many more features listed below.


The following list showcases the most significant features of the plugin I (and other contributors) added during GSoC 2019.

  • Running Dart programs directly from Eclipse - eclipse/dartboard#1

    • Standard & error output in a dedicated console
    • Support for multiple Launch configurations
    • Running single files from the context menu
  • Dart preference page - eclipse/dartboard#10

    • Set the location for the Dart SDK that should be used for all actions
    • Choose whether to automatically synchronize the dependencies of project
  • First class Pub support - eclipse/dartboard#107

    • Automatic synchronization of Pub dependencies when changing the pubspec.yaml file
    • Shortcut for running $ pub get manually
  • Creating new Dart projects and files - eclipse/dartboard#115

    • Stagehand templates are also supported
  • Usage of the Dart logo - eclipse/dartboard@a23fc1f

  • Import existing Dart projects directly into the workspace (+ automatic dependency synchronization) - eclipse/dartboard#116

Upstream Bug Fixes

During development I encountered many issues with the libraries and tools I was using. As I was already aware I took the time to fix them directly and provide a patch or PR for the corresponding library.

Things Left to do

I have completed all of my goals I set in the initial proposal for GSoC. However a few things and features have come up during development that I plan on taking care of in the near future.

  • Flutter support - Flutter apps need to be run using the special $ flutter command suite, instead of the default SDK

Other things that could be enhanced include:

  • Pub console - Currently there is now way to see the output of the pub commands
  • Webdev support - Dart apps that should be run on the browser need to be run using the $ webdev command line tools

I hope to be able to work on them but community contributions are always welcome.

A full list of commits and issues can be found on the project's GitHub repository. Installation instructions can also be found there.


In the early days, Lakshminarayana Nekkanti has joined the project as a committer. He has been extremely helpful since by fixing bugs in the Eclipse platform that have been open for years (Bug 513034) and contributing a lot of features and knowledge to the plugin. Thank you, Lakshminarayana!

I would also like to thank Lars Vogel who has been my Mentor and helped tremendously when I was unsure what to do.

August 19, 2019 12:00 AM

Scaffolding a JSON Forms application with Yeoman

by Jonas Helming and Maximilian Koegel at August 14, 2019 10:15 AM

JSON Forms is a framework for efficiently developing form-based UIs based on JSON Schema.  It provides a simple declarative JSON-based language...

The post Scaffolding a JSON Forms application with Yeoman appeared first on EclipseSource.

by Jonas Helming and Maximilian Koegel at August 14, 2019 10:15 AM

Two Years and Fifty Blogs

by Donald Raab at August 09, 2019 03:53 AM

Happy Blogiversary

Grounds for Sculpture, Hamilton Township, NJ

Welcome to Medium

Two years ago, I wrote my first blog. It was about Symmetry in API design.

Symmetric Sympathy

Writing this blog was one of the hardest and most rewarding things I have done in my career as a software developer.

I have been blogging at least once a month ever since. In the following sections I will share the most popular and my personal favorite blogs for each of the three calendar years I have been blogging. Enjoy!

2017 — Finding My Voice

I write a lot about the Java programming language and Eclipse Collections. I am the creator of Eclipse Collections and am still an active Project Lead and Committer for the project at the Eclipse Foundation, so that should help explain why I write about it.

My top blog in 2017 was “Nine Features in Eclipse Collections 9.0”.

Nine Features in Eclipse Collections 9.0

My personal favorite blog in 2017 was “Preposition Preference”.

Preposition Preference

2018 — Finding My Way

In 2018 was nominated and selected as a Java Champion. I was humbled and honored to be selected into this group of amazingly talented and respected Java luminaries.

My top blog in 2018 was “Ten reasons to use Eclipse Collections”.

Ten reasons to use Eclipse Collections

My personal favorite blog in 2018 was “The 4am Jamestown-Scotland ferry and other optimization strategies”.

The 4am Jamestown-Scotland ferry and other optimization strategies

2019 — Continuing to Tell My Story

I hope to share more about myself and my general views on software development in 2019. I hope to write some blogs about the Smalltalk programming language and environment. I will keep blogging about Eclipse Collections and Java as well I’m sure, especially as we look to the future after the 10.0 release. Java has been changing a lot since Java 8 was released. There is a lot of excitement again around this now twenty four year old programming language.

My top blog in 2019 so far is “Eclipse Collections 10.0 Released”.

Eclipse Collections 10.0 Released

My personal favorite blog so far in 2019 is “Graduating from Minimal to Rich Java APIs”.

Graduating from Minimal to Rich Java APIs

On to 2020 — Finding More Bloggers

I’m heading to Oracle CodeOne in a few weeks to give a talk, meet with old friends, hopefully make some new friends, and spend time teaching and learning as much as I can. I have a new sense of community and purpose since I was selected as a Java Champion. I want to help more bloggers find their voices. It is hard to write, and very hard to write regularly, but it is so critically important to leave a bit of what we know to the current and future generations of developers to learn from.

Thank you for taking the time to read my blogs. I hope you enjoy them and learn something useful from them now and again.

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.

Two Years and Fifty Blogs was originally published in Oracle Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Donald Raab at August 09, 2019 03:53 AM

Update for Jakarta EE community: August 2019

by Tanja Obradovic at August 06, 2019 03:55 PM

We hope you’re enjoying the Jakarta EE monthly email update, which seeks to highlight news from various committee meetings related to this platform. There’s a lot happening in the Jakarta EE ecosystem so if you want to get a richer insight into the work that has been invested in Jakarta EE so far and get involved in shaping the future of Cloud Native Java, read on. 

Without further ado, let’s have a look at what happened in July: 

EclipseCon Europe 2019: Record-high talk submissions

With your help, EclipseCon Europe 2019 reported record-high talk submissions. Thank you all for proposing so many interesting talks! This is not the only record, though: it seems that the track with the biggest number of submissions is Cloud Native Java so if you want to learn how to develop applications and cloud native microservices using Java, EclipseCon Europe 2019 is the place to be. The program will be announced the week of August 5th. 

Speaking of EclipseCon Europe, you don’t want to miss the Community Day happening on October 21; this day is jam-packed with peer-to-peer interaction and community-organized meetings that are ideal for Eclipse Working Groups, Eclipse projects, and similar groups that form the Eclipse community. Plus, there’s also a Community Evening planned for you, where like-minded attendees can share ideas, experiences and have fun! That said, in order to make this event a success, we need your help. What would you like the Community Day & Evening to be all about? Check out this wiki first, then make sure to go over what we did last year. And don’t forget to register for the Community Day and/or Community Evening! 

EclipseCon Europe will take place in Ludwigsburg, Germany on October 21 - 24, 2019. 

JakartaOne Livestream: Registration is open!

Given the huge interest in the Cloud Native Java track at EclipseCon Europe 2019, it’s safe to say that JakartaOne Livestream, taking place on September 10, is the fall virtual conference spanning multiple time zones. Plus, the date coincides with the highly anticipated Jakarta EE 8 release so make sure to save the date; you’re in for a treat! 

We hope you’ll attend this all-day virtual conference as it unfolds; this way, you get the chance to interact with renowned speakers, participate in interesting interactions and have all your questions answered during the interactive sessions. Registration is now open so make sure to secure your spot at JakartaOne Livestream! 

No matter if you’re a developer or a technical business leader, this virtual conference promises to satisfy your thirst for knowledge with a balance of technical talks, user experiences, use cases and more. The program will be published soon. Stay tuned!

Jakarta EE 8 release

On September 10, join us in celebrating the Jakarta EE 8 release at JakartaOne Livestream!  

That being said, head over to GitHub to keep track of all the Eclipse EE4J projects. Noticeable progress has been made on Final Specifications Releases, Jakarta EE 8 TCK jobs, Jakarta Specification Project Names, and Jakarta Specification Scope Statements so make sure to check out the progress and contribute!  

Jakarta EE Trademark guidelines: Updates 

Version 1.1 of the Jakarta EE Trademark Guidelines is out! This document supplements the Eclipse Foundation Guidelines for Eclipse Logos & Trademarks Policy to address the permitted usage of the Jakarta EE Marks, including the following names and/or logos: 

  • Jakarta EE

  • Jakarta EE Working Group

  • Jakarta EE Member 

  • Jakarta EE Compatible 

The full guidelines on the usage of the Jakarta EE Marks are described in the Jakarta EE Brand Usage Handbook

EFSP: Updates

Version 1.2 of the Eclipse Foundation Specification Process was approved on June 30, 2019. The EFSP leverages and augments the Eclipse Development Process (EDP), which defines important concepts, including the Open Source Rules of Engagement, the organizational framework for open source projects and teams, releases, reviews, and more.

JESP: Updates

Jakarta EE Specification Process v1.2 was approved on July 16, 2019. The JESP has undergone a few modifications, including 

  • changed ballot periods for the progress and release (including service releases) reviews from 30 to 14 days

  • the Jakarta EE Specification Committee now adopts the EFSP v1.2 as the Jakarta EE Specification Process

TCK process finalized 

The TCK process has been finalized. The document sheds light on aspects such as the materials a TCK must possess in order to be considered suitable for delivering portability, the process for challenging tests and how to resolve them and more.     

This document defines:

  • Materials a TCK MUST possess to be considered suitable for delivering portability

  • Process for challenging tests and how these challenges are resolved

  • Means of excluding released TCK tests from certification requirements

  • Policy on improving TCK tests for released specifications

  • Process for self-certification

Jakarta EE Community Update: July video call

The most recent Jakarta EE Community Update meeting took place in mid-July; the conversation included topics such as Jakarta EE 8 release, status on progress and plans, Jakarta EE TCK process update, brief update re. transitioning from javax namespace to the jakarta namespace, as well as details about JakartaOne Livestream and EclipseCon Europe 2019.   

The materials used in the Jakarta EE community update meeting are available here and the recorded Zoom video conversation can be found here.  

Please make sure to join us for the August 14  community call.

Cloud Native Java eBook: Coming soon!

What does cloud native Java really mean to developers? What does the cloud native Java future look like? Where is Jakarta EE headed? Which technologies should be part of your toolkit for developing cloud native Java applications? 

All these questions (and more!) will be answered soon; we’re developing a downloadable eBook on the community's definition and vision for cloud native Java, which will become available shortly before Jakarta EE 8 is released. Stay tuned!

Eclipse Newsletter: Jakarta EE edition  

The Jakarta community has made great progress this year and the culmination of all this hard work is the Jakarta EE 8 release, which will be celebrated on September 10 at JakartaOne Livestream

In honor of this milestone, the next issue of the Eclipse Newsletter will focus entirely on Jakarta EE 8. If you’re not subscribed to the Eclipse Newsletter, make sure to do that before the Jakarta EE issue is released - on August 22! 

Meet the Jakarta EE Working Group Committee Members 

It takes a village to create a successful project and the Jakarta EE Working Group is no different. We’d like to honor all those who have demonstrated their commitment to Jakarta EE by presenting the members of all the committees that work together toward a common goal: steer Jakarta EE toward its exciting future. As a reminder, Strategic members appoint their representatives, while the representatives for Participant and Committer members were elected in June.

The list of all Committee Members can be found here

Steering Committee 

Will Lyons (chair)- Oracle, Ed Bratt - alternate

Kenji Kazumura - Fujitsu, Michael DeNicola - alternate

Dan Bandera - IBM, Ian Robinson - alternate

Steve Millidge - Payara, Mike Croft - alternate

Mark Little - Red Hat, Scott Stark - alternate

David Blevins - Tomitribe, Richard Monson-Haefel alternate

Martijn Verburg - London Java Community - Elected Participant Representative

Ivar Grimstad - Elected Committer Representative

Specifications Committee 

Kenji Kazumura - Fujitsu, Michael DeNicola - alternate

Dan Bandera - IBM, Kevin Sutter - alternate

Bill Shannon - Oracle, Ed Bratt - alternate

Steve Millidge - Payara, Arjan Tijms - alternate

Scott Stark - Red Hat, Mark Little - alternate

David Blevins - Tomitribe, Richard Monson-Haefel - alternate

Ivar Grimstad - PMC Representative

Alex Theedom - London Java Community Elected Participant Representative

Werner Keil - Elected Committer Representative

Paul Buck - Eclipse Foundation (serves as interim chair, but is not a voting committee member)

Marketing and Brand Committee

Michael DeNicola - Fujitsu, Kenji Kazumura - alternate 

Dan Bandera - IBM, Neil Patterson - alternate

Ed Bratt - Oracle, David Delabassee - alternate

Dominika Tasarz - Payara, Jadon Orglepp - alternate

Cesar Saavedra - Red Hat, Paul Hinz - alternate

David Blevins - Tomitribe, Jonathan Gallimore - alternate

Theresa Nguyen - Microsoft Elected Participant Representative

VACANT - Elected Committer Representative

Thabang Mashologu - Eclipse Foundation (serves as interim chair, but is not a voting committee member)

Jakarta EE presence at events and conferences: July overview 

Cloud native was the talk of the town in July. Conferences such as JCrete, J4K, and Java Forum Stuttgart, to name a few, were all about open source and cloud native and how to tap into this key approach for IT modernization success. The Eclipse Foundation and the Jakarta EE Working Group members were there to take a pulse of the community to better understand the adoption of cloud native technologies. 

For example, IBM’s Graham Charters and Steve Poole featured Jakarta EE and Eclipse MicroProfile in demonstrations at the IBM Booth at OSCON; Open Source Summit 2019 participants should expect another round of Jakarta EE and Eclipse MicroProfile demonstrations from IBM representatives. 

Thank you for your interest in Jakarta EE. Help steer Jakarta EE toward its exciting future by subscribing to the mailing list and by joining the Jakarta EE Working Group. Don’t forget to follow us on Twitter to get the latest news and updates!

To learn more about the collaborative efforts to build tomorrow’s enterprise Java platform for the cloud, check out the Jakarta Blogs and participate in the monthly Jakarta Tech Talks. Don’t forget to subscribe to the Eclipse newsletter!  


Links you may want to bookmark!

The Jakarta EE community promises to be a very active one, especially given the various channels that can be used to stay up-to-date with all the latest and greatest. Tanja Obradovic’s blog offers a sneak peek at the community engagement plan, which includes

Note: All the upcoming Jakarta Tech Talks can be found in the calendar. If you’d like to learn more about Jakarta EE-related plans and get involved in shaping the future of cloud native Java, please bookmark the Jakarta EE Community Calendar.


by Tanja Obradovic at August 06, 2019 03:55 PM

Dartboard: Pub support, Stagehand templates & better theming

August 03, 2019 12:00 AM

Automatic dependency synchronization, stagehand templates and theme improvements for TM4E.

Pub dependency synchronization is the main source of packages for Dart projects. Dependencies are added to a pubspec.yaml file and the $ pub get command is used to download the packages from the registry. Since most projects require at least a few dependencies this step must be taken before the project compiles without errors.

To ease this process a little, the command is now automatically run when saving the pubspec.yaml file in Eclipse. With this, required dependencies are automatically downloaded when a project is imported or when a new package is added to the pubspec.yaml file.

If you don't want this behavior the feature can be disabled from the preference page. Manually running the synchronization is also supported from the context menu of a project.

Pub context handler

The current progress of the synchronization is reported to the Progress view.

Pub progress


Stagehand is a CLI tool, written in Dart, that generates new projects from a list of templates. There are different project types to chose from, like Flutter, AngularDart or just console applications. After a template is generated the project contains a pubspec.yaml file containing all necessary dependency information and various entry files that are required by the type of project.

This tool is now supported graphically by the New Dart Project wizard also provided by Dartboard. Under the hood the plugin uses the exact executable from And by automatically updating it we make sure that new templates can be immediately used.

This is how the New Dart Project wizard looks now: Stagehand

At first selection of the Wizard (after a fresh IDE start) Stagehand is updated and its templates are fetched. After that job is finished the available templates are added to the combo box. If no template should be used the Use Stagehand template checkbox can be unchecked and an empty project is generated.

Subsequent usages of the wizard use cached versions of the templates list to not strain your network or the registry too much.

Project import

Not every Dart project was created from Eclipse though. So to be able to use Dartboard with existing Dart projects it is required to import them into the workspace. For this task we now provide a shortcut to import Dart projects from the Import Project context menu entry.

Currently it simply opens the Projects from Folder or Archive wizard. This wizard however allows to specify a ProjectConfigurator that takes care of selecting folders that should be imported as a project. In our own configurator we traverse all children and look for pubspec.yaml files. Every folder that contains such a file is considered to be a separate project.

Eclipse light theme for TM4E

TM4E can be used to apply different syntax highlighting to the editor. We provide a configuration file that specifies how certain words inside the editor should look. It also gives the option to select what theme to use. There are different light and dark themes available, like Solarized Light or the classic Eclipse Java editor theme.

I provided a patch to add some missing styles to the latter to make it look more like the classic theme. This is what it looks like now: Eclipse light theme

See eclipse/tm4e#215.

Wrap up

With two weeks to go until the end of Summer of Code 2019 there is not that much left to do for me to fulfill my proposed timeline. One major thing that is still missing are automated tests. I have started work on it now and will work on that for the last two weeks.

This will also be my last update post on Summer of Code as the next post will be a summary of my whole summer.

August 03, 2019 12:00 AM

KubeCon Shanghai 2019: Cloud Native at China Scale

by Chris Aniszczyk at July 29, 2019 04:08 PM

Last month, we held KubeCon + Cloud NativeCon in Shanghai, one of the largest open source events in China. Recently, we published the conference transparency report detailing how the 3500 person event went but I’d like to share a couple take aways as someone who has been traveling to China quite a bit the last few years.

Cloud Native at China Scale

The scale of operating a popular service in China can be wild when you serve a billion users. This forces many of these companies to operate in a cloud native fashion, similar to their internet scale peers in Silicon Valley. I strongly believe we will see more interesting open source technology born in China over the next decade as they deal with scaling issues, similar to how a lot of internet scale open source technology was born from Google and other SV companies that had to support a larger user base. I highly recommend this great interview from Kevin Xu highlights some of the scale and open source projects coming out of China.

Also, Ant Financial joined CNCF as a Gold End User member, which is indicative of the trends of Chinese companies supporting open source they depend on and sharing the lessons they have learned. For those that aren’t aware, Ant Financial is the largest mobile payments company in the world (Alipay), running on Kubernetes and other CNCF projects. You can read their CNCF Case study here how they run on tens of thousands of Kubernetes nodes serving nearly a billion Alipay customers.

Giving Back: China: #2 contributor to Kubernetes

For those who aren’t aware, China is the second largest contributor to Kubernetes (and third to CNCF projects overall).


It’s always great to have consumers contribute code back as that’s one important way how open source is sustainable in the long run.

On the whole, it was a fantastic to spend time with our cloud native community in Shanghai and we look forward to coming back to China next year, stay tuned for details for KubeCon + CloudNativeCon 2020 China! For now, we look forward to seeing many folks at KubeCon + CloudNativeCon 2019 San Diego which is gearing to be one of the largest open source events in the world.

by Chris Aniszczyk at July 29, 2019 04:08 PM

Pimping the status line

by Andrey Loskutov ( at July 28, 2019 04:50 PM

This weekend I've tried to write a test for Eclipse debug hover, that required to know exact position of the selected text, somewhere in the middle of the editor. If you think this is easy - go figure out in Eclipse at which offset is your cursor - surprisingly there is no obvious way to do so!

So I've used some 3rd party editor that was kind enough to provide this information in the status line. Why shouldn't this be offered by Eclipse itself?

So I've created an enhancement request and pushed patch that adds both features to Eclipse. By default, status line shows now cursor position, and if editor has something selected, the number of characters in the selection (works also in block selection mode). Both new additions to the status line can be disabled via preferences.

 If there is no selection, cursor offset is shown:

Both new additions to the status line can be disabled via preferences:

by Andrey Loskutov ( at July 28, 2019 04:50 PM

Incompatible Eclipse workspaces

by Andrey Loskutov ( at July 28, 2019 04:35 PM

Eclipse has mechanism to recognize if the workspace to be used is created with older Eclipse version.
In such case, to be safe, Eclipse shows dialog like:

As of today (Eclipse 4.12 M1), if you click on "Cancel" button, Eclipse will behave differently, depending on the use cases "history":

A. If the workbench was not started yet:

  1. If Eclipse was started without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog.
  2. If Eclipse was started with "-data" argument pointing to the incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).

B. If the workbench was started:

  1. If user selects compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine.
  2. If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).
This behavior is inconvenient (at least), so we have bug 538830.

Fix Proposal #1

The proposal is, that independently on the way Eclipse was started, if user clicks on the "Cancel" button in the "Older Workspace Version" dialog, we always show the default workspace selection dialog (instead of termination):

In this dialog above user has two choices: launch any workspace or finally terminate Eclipse via "Cancel".

Proposal #1 Matrix

A1. If the workbench was not started yet:

  1. If Eclipse was started with or without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog. To terminate Eclipse, user has to click "Cancel" in the workspace selection dialog.

B1. If the workbench was started:

  1. If user selects compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine.
  2. If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer to select another workspace.

Fix Proposal #2

The proposal is, that depending on the way Eclipse was started, if user clicks on the "Cancel" button in the "Older Workspace Version" dialog, we may or may not show the default workspace selection dialog. So what happens after "Older Workspace Version" dialog is shown is not predictable by just looking on this dialog - it depends on the history of this dialog.

Proposal #2 Matrix

A2. If the workbench was not started yet:

  1. If Eclipse was started without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog.
  2. If Eclipse was started with "-data" argument pointing to the incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).

B2. If the workbench was started:

  1. If user selects compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine.
  2. If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer to select another workspace.


Both proposals fix second bullet in the use case B2.


We see that Proposal #1 has no second bullet for A1 case, and is always consistent in the way how UI behaves after clicking on "Cancel" in the "Older Workspace Version" dialog. Proposal #2 fixes only B2 use case, inconsistency in UI behavior for the second part of A1 use case remains.

Technical (biased) notes:

  1. Proposal #1 is implemented and the patch is available, along with the demo video. To test it live, one has to build Eclipse - but here I have SDK binaries with the patch applied. The patch is relatively simple and only affects Platform UI internal code.
  2. Proposal #2 is not implemented yet. I assume that this will require more work compared to the patch #1. We will need a new command line argument for Eclipse to differentiate between "I want you not to terminate even if incompatible -data is supplied because I'm calling you from UI" and "Please terminate if incompatible data is supplied because I'm calling you from the command line". A new command line argument for Eclipse means not just Platform UI internal change, but also requires changes in the Equinox and Help, and also means public interface change.

Question to the masses!

We want to know your opinion - which proposal should be implemented?

Please reply here or on the bug 538830.


This version was implemented and available in 4.13 M1:

by Andrey Loskutov ( at July 28, 2019 04:35 PM

React App Development in N4JS (Chess Game Part 1)

by n4js dev ( at July 16, 2019 09:47 AM

React is a popular JavaScript library created by Facebook widely used for developing web user interfaces. In this post we introduce a tutorial on how to develop a chess game based on React, JSX and N4JS. The full tutorial is available (and playable) at and the sources can be found at

Chess game implemented in N4JS with React

The chess game app implements the following requirements:
  • When the chess application is started, a chess board of 8x8 squares shall be showed containing 16 white pieces and 16 black pieces in their initial positions.
  • A player in turn shall be able to use the mouse to pick one of the pieces that she/he wants to move. A picked piece shall be clearly recognisable. Moreover, to aid players, especially beginners, whenever a piece is picked, all possible valid destination squares shall be visually highlighted as well.
  • In addition to the game board, there shall be a game information area that shows which player is in turn. Moreover, the game information area shall show a complete history of the game protocolling each move made by the players. As a bonus, jumping back to a previous state of the history shall be possible.

In the tutorial you will learn how to use npm, webpack and React to develop a web application with N4JS and the N4JS IDE. Most of the tutorial will elaborate on specific parts of the implementation and explain for example the graphical representation of the chess board and chess pieces, and how to use React to model the UI. Also, it will explain the game logic, i.e. how possible moves for the different piece types are computed, how the turn history is maintained, and how the end of the game (i.e. a win situation) is detected. In the end, the tutorial will make suggestions on how to improve the chess game e.g. by adding support for the en passant move.

Have fun with implementing this game!

by Minh Quang Tran

by n4js dev ( at July 16, 2019 09:47 AM

Commercial-Grade Collaboration at the Eclipse Foundation

by Thabang Mashologu at July 15, 2019 03:04 PM

When it comes to the digital economy, business runs on open source. That’s because open source is the best way to deliver large-scale business innovation and value at the pace customers expect. We’ve just released a Business of Open Source eBook that is essential reading for leaders in the age of digital disruption who are considering how to maximize their returns from open source participation.


For the last 15 years, companies ranging from startups to industry leaders the likes of Bosch, Broadcom, Fujitsu, Google, IBM, Microsoft, Oracle, Red Hat, SAP, and more have collaborated under the Eclipse governance model to advance open source projects and create value for their stakeholders. In this latest publication, we explore the role of open source as a pillar for transformation initiatives and the unique position of the Eclipse Foundation as the home of community-driven, code-first, and commercial-ready open source technologies.


Featuring interviews from leading open source industry experts, this eBook sheds light on how hundreds of organizations have leveraged the Foundation’s clear, vendor-neutral rules for intellectual property sharing and decision-making, business-friendly licensing, and ecosystem development and marketing services to accelerate market adoption, mitigate business risk, and harness open source for business growth while giving back to the developer community.


Deborah Bryant, Senior Director, Open Source Program Office at Red Hat, puts it this way in the eBook: “The Eclipse Foundation has a rich history of being an industry disrupter...It distinguishes itself in its long history and deep roots with large industry players. The Foundation has really been driven by engineers for engineers, but also as an honest broker of discussions with the business of these big companies that are doing very large-scale projects.”


Are you leveraging all that open source has to offer? Do you understand the value of participating in open source to develop customer-centric products and services faster? Do you recognize the scalability of open source, the ability to innovate on business models, and the ability to collaborate with a global developer community? Congratulations, you’re what we like to call an entr<open>eur. To get the most out of your stake in open source, it's time to consider joining a commercially-friendly open source foundation like ours.


To learn more about the business value of open collaboration at the Eclipse Foundation, visit In addition to the eBook, you’ll find video success stories from the Eclipse community, an infographic summarizing the role and benefits of participating in an open source foundation, and an informative slide deck that you can use to make the case for joining the Eclipse Foundation. Many thanks to Deborah Bryant, Todd Moore, and Tyler Jewell for contributing their expertise and insights to the eBook.


Let us know what you think and be sure to join the entrepreneurial open source conversation on Twitter @EclipseFdn and share your open source success story using #entropeneur.

by Thabang Mashologu at July 15, 2019 03:04 PM

Papyrus SysML 1.6 available from the Eclipse Marketplace.

by tevirselrahc at July 12, 2019 02:03 PM

I should have mentioned, yesterday, that Papyrus SysML 1.6 is available from the Eclipse market place at

by tevirselrahc at July 12, 2019 02:03 PM

Papyrus 4.4 is available

by tevirselrahc at July 12, 2019 07:15 AM

I’m a bit late with this posting…better late than never!

A new version of papyrus 4.4 is available:

SysML1.6 ( a forum topic will be send when the market place is available)

  • SysML 1.6 profile done
  • The SysML requirement diagram shall be implemented
  • The SysML Parametric diagram shall be implemented
  • The SysML BDD shall be implemented
  • The SysML IBD shall be implemented
  • The SysML requirement table shall be implemented
  • The SysML Graphical element type shall be implemented
  • The SysML AF shall be implemented
  • The SysML allocation Matrix shall be implemented
  • The elementype of SysML 1.6 shall be implemented
  • Make SysML 1.6 open source
  • The SysML model explorer customization shall be implemented
  • Add written OCL constraints
  • Implement E3 of SysML 1.6
  • Update SysML 1.6 diagram of profile
  • Add Icon for conjugated Interface block
  • Add compartment of Conjugated Interfaceblock inside BDD
  • The SysML Junit Test shall be implemented
  • Papyrus shall support the migration from SysML 1.4 to 1.6 Papyrus toolsmith

Validation of plugins:

  • you have done your profile to customize papyrus, but you forget extension point, build.xml, dependencies. We have done a work not only to validate profile but the plugin that contains the profile
  • the work has also be done for plugins that contain elementTypes model.

Improve developer experience to use plugin org.eclipse.papyrus.infra.core.sasheditor

  • Decrease the usage of internal eclipse code
  • Papyrus has developed at the beginning a new kind of editor compnoent sasheditor. To be more stable, we have ask to open api to eclipse in order to improve integration to eclipse.
  • Dedicated API have been created from use cases in order to help developer to access to this graphical composite; add a new editor inside papyrus, get active editor…
  • These usecases will be published inside a plugin developer doc :
  • It is will be like a javadoc that has a list of use cases and references API that implement these usecases.


  • Papyrus will provide a documentation generator targeting LibreOffice file (odt).
  • This generator will allow to the user to describe how to cross the UML model to create the document
  • This generator will allow to the user to define a document template to use for the generation
  • This generator will support image and table insertion.

Go try it and send me your comments!


by tevirselrahc at July 12, 2019 07:15 AM

Announcing Eclipse Ditto Release 0.9.0

July 10, 2019 04:00 AM

Today the Eclipse Ditto team proudly presents its second release 0.9.0.

The topics of this release in a nutshell were:

  • Memory improvements for huge amounts (multi million) of digital twins which are held in memory
  • Adding metrics and logging around the connectivity feature in order to enable being able to operate connections to foreign systems/brokers via APIs
  • Enhancing Ditto’s connectivity feature by additionally being able to connect to Apache Kafka
  • Performance improvements of Ditto’s search functionality
  • Stabilization of cluster bootstrapping
  • Refactoring of how the services configurations are determined
  • Addition of a Helm template in order to simplify Kubernetes based deployments
  • Contributions from Microsoft in order to ease operating Eclipse Ditto on Microsoft Azure

Please have a look at the 0.9.0 release notes for a more detailed information on the release.


The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central.

The Docker images have been pushed to Docker Hub:


The Eclipse Ditto team

July 10, 2019 04:00 AM

Building UIs with EASE

by Christian Pontesegger ( at July 08, 2019 06:54 PM

You probably used EASE before to automate daily tasks in your IDE or to augment toolbars and menus with custom functionality. But so far scripts could not be used to build UIs. This changed with the recent contribution of the UI Builder module.

What it is all about
The UI Builder module allows to create views and dialogs by pure script code in your IDE. It is great for custom views that developers do not want to put into their products, for rapid prototyping and even for mocking.

The aim of EASE is to hide layout complexity as much as possible and provide a simple, yet flexible way to implement typical UI tasks.

Example 1: Input Form
We will start by creating a simple input form for address data.

loadModule("/System/UI Builder");
createView("Create Contact");

createLabel("First Name:");
var txtFirstName = createText();
createLabel("Last Name:");
var txtLastName = createText();
This snippet will create a dynamic view as shown below:
The renderer used will apply a GridLayout. By setting the columnCount to 2 we may simply add our elements without providing any additional layout information - a simple way to create basic layouts.

If needed EASE provides more control by providing layout information when creating components:

createView("Create Contact");
createLabel("First Name:", "1/1 >x");
var txtFirstName = createText("2-4/1 o!");
createLabel("Last Name:", "1/2 >x");
var txtLastName = createText("2-4/2 o!");
Creates the same view as above, but now with detailed layout information.
As an example "1/2 >x" means: first column, second row, horizontal align right, vertical align middle. A full documentation on the syntax is provided in the module documentation (Hover over the UI Builder module in the Modules Explorer view).

Now lets create a combo viewer to select a country for the address:
cmbCountry = createComboViewer(["Austria", "Germany", "India", "USA"])
Simple, isn't it?

So far we did not need to react on any of our UI elements. Next step is to create a button which needs some kind of callback action:
createButton("Save 1", 'print("you hit the save button")')
createButton("Save 2", saveAddress)

function saveAddress() {
print("This is the save method");
The first version of a button adds the callback code as string argument. When the button gets pressed, the callback code will be executed. You may call any script code that the engine is capable of interpreting.

The second version looks a bit cleaner, as it defines a function saveAddress() which is called on a button click. Note that we provide a function reference to createButton().

View the full example of this script on our script repository. In addition to some more layouting it also contains a working implementation of the save action to store addresses as JSON data files.

Interacting with SWT controls

The saveAddress() method needs to read data from the input fields of our form. This could be done using
var firstName = txtFirstName.getText();
Unfortunately SWT Controls can only be queried in the UI thread, while the script engine is executed in its own thread. To move code execution to the UI thread, the UI module provides a function executeUI(). By default this functionality is disabled as a bad script executed in the UI thread might stall your Eclipse IDE. To enable it you need to set a checkbox in Preferences/Scripting. The full call then looks like this:
var firstName = executeUI('txtFirstName.getText();');

Example 2: A viewer for our phone numbers

Now that we are able to create some sample data, we also need a viewer for our phone numbers. Say we are able to load all our addresses into an array, the only thing we need is a table viewer to visualize our entries. Following 2 lines will do the job:
var addresses = readAddresses();
var tableViewer = createTableViewer(addresses)
Where readAddresses() collects our *.address files and stores them into an array.

So the viewer works, however we need to define how our columns shall be rendered.
createViewerColumn(tableViewer, "Name", createLabelProvider("getProviderElement().firstName + ' ' + getProviderElement().lastName"))
createViewerColumn(tableViewer, "Phone", createLabelProvider("getProviderElement().phone"))
Whenever a callback needs a viewer element, getProviderElement() holds the actual element.
We are done! 3 lines of code for a TableViewer does not sound too bad, right? Again a full example is available on our script repository. It automatically loads *.address files from your workspace and displays them in the view.

Example 3: A workspace viewer

We had a TableViewer before, now lets try a TreeViewer. As a tree needs structure, we need to provide a callback to calculate child elements from a given parent:
var viewer = createTreeViewer(getWorkspace().getProjects(), getChildren);

function getChildren() {
if (getProviderElement() instanceof org.eclipse.core.resources.IContainer)
return getProviderElement().members();

return null;
So simple! The full example looks like this:
Example 4: Math function viewer

The last example demonstrates how to add a custom Control to a view.
For plotting we use the Charting module that is shipped with EASE. The source code should be pretty much self explanatory.

Some Tips & Tricks

  • Layouting is dynamic.
    Unlike the Java GridLayout you do not need to fill all cells of your layout. The EASE renderer takes care to automatically fill empty cells with placeholders
  • Elements can be replaced.
    If you use coordinates when creating controls, you may easily replace a given control by another one. This simplifies the process of layouting (eg if you experience with alignments) and even allows a view to dynamically change its components depending on some external data/events
  • Full control.
    While some methods from SWT do not have a corresponding script function, still all SWT calls may be used as the create* methods expose the underlying SWT instances.
  • Layout help.
    To simplify layouting use the showGrid() function. It displays cell borders that help you to see row/column borders.

by Christian Pontesegger ( at July 08, 2019 06:54 PM

Eclipse Milo 0.3, updated examples

by Jens Reimann at July 06, 2019 08:22 PM

We while back I wrote a blog post about OPC UA, using Milo and added a bunch of examples, in order to get you started. Time passed by and now Milo 0.3.x is released, with a changed API and so those examples no longer work. Not too much has changed, but the experience of running into compile errors isn’t a good one. Finally I found some time to update the examples.

This blog post will focus on the changes, compared to the old blog post. As the old blog post is still valid, I though it might make sense to keep it, and introduce the changes of Milo here. The examples repository however is updated to show the new APIs on the master branch.

Making contact

This is the first situation where you run into the changed API, getting the endpoints. Although the new code is not much different, the old will no longer work:

List<EndpointDescription> endpoints =

When you compare that to the old code, then you will notice that instead of an array, now a list is being used and the class name changed. Not too bad.

Also, the way you create a new client instance with Milo 0.3.x is a bit different now:

OpcUaClientConfigBuilder cfg = new OpcUaClientConfigBuilder();
cfg.setEndpoint(endpoints[0]); // please do better, and not only pick the first entry

OpcUaClient client = OpcUaClient.create(;

Using the static create method instead of the constructor allows for a bit more processing, before the class instance is actually created. Also may this new method throw an exception now. Handling this in an async way isn’t too hard when you are using Java 9+:

public static CompletableFuture<OpcUaClient> createClient(String uri) {
  return DiscoveryClient
    .getEndpoints(uri) // look up endpoints from remote
    .thenCompose(endpoints -> {
      try {
        return CompletableFuture.completedFuture(
            OpcUaClient.create(buildConfiguration(endpoints)) // "buildConfiguration" should pick an endpoint
      } catch (final UaException e) {
        return CompletableFuture.failedFuture(e);

That’s it? That’s it!

Well, pretty much. However, we have only been looking at the client side of Milo. Implementing your own server requires to use the server side API, and that change much more. But to be fair, the changes improve the situation a lot, and make things much easier to use.

Milo examples repository

As mentioned, the examples in the repository ctron/milo-ece2017 have been updated as well. They also contain the changed server side, which changed a lot more than the client side.

When you compare the two branches master and milo-0.2.x, you can see the changed I made for updating to the new version.

I hope this helps a bit in getting started with Milo 0.3.x. And please be sure to read the original post, giving a more detailed introduction, as well.

The post Eclipse Milo 0.3, updated examples appeared first on ctron's blog.

by Jens Reimann at July 06, 2019 08:22 PM

Current State of C/C++ Language Servers

by Doug Schaefer at June 28, 2019 07:59 PM

A Bit of History

When I joined the Eclipse CDT project back in 2002 (yeah, it’s been a long time), I was working on modeling tools for “real time”, or more accurately, embedded reactive systems. Communicating state machines. I wrote code generators that generated C and C++ from ROOM models and then eventually UML-RT. ROOM was way better by the way and easier to generate for because it was more semantically complete and well defined. That objective is key later in this story.

We had the vision to integrate our modeling tools more closely with Integrated Development Environments. We started looking at Visual Studio but Eclipse was the young up and comer. That and IBM bought us, Rational by that point, and had already bought OTI who built Eclipse so it was a natural fit. And we were all in Ottawa. And by chance, Ottawa-based QNX had already written a C/C++ IDE based on Eclipse and were open sourcing it and it was perfect for our customers as well. It’s amazing how that all happened and led to my life as CDT Doug.

Our first order of business was to help the CDT become an industry class C/C++ IDE and become a foundation for integrating our modeling tools. Since we wanted to be able to generate model elements from code, it required we have accurate C and C++ parsers and indexers. No one figured we could do it, but we were able to put together a somewhat decent system written in Java in the org.eclipse.cdt.core plug-in.

Scaling is Hard

However, as the community started to try it out on real projects, especially ones of a significant size, we started to run into pretty massive performance problems with the indexer. We were essentially doing full builds of the user’s projects and storing the results in a string table. On large projects, builds take a long time. But users expect that and put up with it because they really need those binaries it produces. They don’t have the same patience for their IDEs building indexes the don’t really see and we paid a pretty high price for that.

As a solution, I wondered if we could store the symbol information that we were gathering in a way that we could load it up from disk as we were parsing other files and plug the symbol info into the AST the same way we do symbols normally. This would allow us to parse header files once and reuse the results, similar to how precompiled headers work. The price you pay is in accuracy since some systems parse header files multiple times with different macro settings. But my guess was that it wouldn’t be that bad.

It was hard to convince my team at IBM Rational to take this road. Accuracy was king for our modeling tools. But when I moved to join QNX, I decide to forgo that requirement and give this “fast indexer” strategy a go. And the rest is history. Performance on large projects was an order of magnitude faster. Incremental indexing of files as they were saved isn’t even noticeable. It was a huge success and my proudest contribution to the CDT. And I was even better when other community members handed us their expertise to make the accuracy better and better so you barely notice that at all either.

C++ Rises from the “Dead”

Move the clock a decade later and we started running into a problem. The C++ standards community has new life and are adding a tonne of new features at a three year cadence. The CDT community has long lost most of the experts that build the original parsers. Lucky for us a new crop of contributors has come along and are doing heroes work to keep up. But it’s getting harder and harder. One thing we benefit from is how slow embedded developers, the majority of users of CDT, are to adopt the new standards. It gives us time, but not forever. We need to find a better way.

Then along came the Language Server Protocol and a small handful of language servers that do C/C++. I’ve investigated four of them. Three of them are based on llvm and clang. One of them is in tree with llvm and clang in clang-tools-extra, i.e., clangd. The other two are projects that use libclang with parts of the tree, i.e., cquery and ccls. Those two projects are what I call “one person projects” and with cquery at least, that person found something else to do last November. Beware of the one person project.


I’ve spent a lot of time with clangd when experimenting with Visual Studio Code. For what it does, clangd is very accurate and really fast. It uses compile_commands.json files to find out what source files are built and what compiler and command lines they use. I’ve had to fork the tree to add in support for discovering compilers it doesn’t know about, but that was pretty easy to put together. It gives great content assist and you get the benefit of clang’s awesome compilation error diagnostics as you type. It shows a lot of promise.

However clangd for the longest time lacked an indexer. When you search for references it only finds them in files you have opened previously. The thought as I understand it is that you use another process to build the index and that is usually done at build time. However, not all users have such an environment set up so having an index created by the IDE is a mandatory feature. Now, clangd did eventually get an indexer but it does what the old CDT indexer did and completely parses the source three. That predictably takes forever on large projects and I don’t think users have the appetite to take a huge step backwards like that.


While waiting for the right solution to arrive for clangd, I thought I’d give the Microsoft C/C++ Tools for VS Code a try. My initial experience was quite surprising. It actually worked well with a gnu tools cross compiler project I used for testing. You have to teach it how to parse your code using a magic JSON file, which fits right in with the rest of VS Code. It’s able to pick out the default include path when you point it at your compiler. It has a MI support for debugging, though no built-in support for remote debugging but that was hackable. It seemed like a reasonable alternative, at least for VS Code.

However when I tried it with one of our production projects it quickly fell apart. It does a great job trying to figure out include paths, similar to the heuristics we use in CDT. That includes things like treating all the folders in your workspace as a potential include path entry. But it tended to make mistakes. It even has support for compile_commands.json files so I could tell it the command lines that were use. It did better but still tried to do too much and gave incorrect results.

That and it doesn’t have an index yet either. One is coming soon, but if it can’t figure out how to parse my files correctly, it’s not going to be a great experience. Still a lot of work to do there.

Where do we go from here?

As it stands today, at least from a CDT perspective, there really isn’t a language server solution that comes near what we have in CDT. Yes, some things are better. Both these language servers are using real parsers to parse the code. (or at least clangd is. Microsoft’s, of course, is closed source so I can only assume). They give really good content assist and error diagnostics and open declaration works. But without a usable indexer, you don’t get accurate symbol references. And I haven’t even mentioned refactoring which CDT has and which is not even suggested in the language server protocol.

So if all your doing is typing in code, the new language servers are great. But if you need to do some code mining to understand the code before you change it, you’re out of luck. The good news is that we are continuing to see investment in them so who knows. But then, maybe the CDT parsers catch up with the language standards before these other language servers grow great indexers making the whole thing moot. I wouldn’t bet against that right now.

by Doug Schaefer at June 28, 2019 07:59 PM

Graphical Editing Framework (GEF) 5.1.0 Release

by Tamas Miklossy ( at June 25, 2019 08:00 AM

The Eclipse GEF team is happy to announce that version 5.1.0 of the Eclipse Graphical Editing Framework is part of the Eclipse 2019-06 simultaneous release:




The project team has worked hard since the Eclipse GEF 5.0.0 release two years ago. The new release fixes issues on the GEF MVC, GEF Zest, and GEF DOT components.

We would like to thank all contributors who made this release possible:



Your feedback regarding the new release is highly appreciated. If you have any questions or suggestions, please let us know via the Eclipse GEF forum or create an issue on Eclipse Bugzilla.

For further information, we recommend to take a look at the Eclipse GEF blog articles, watch the Eclipse GEF session on the EclipseCon Europe 2018, and try out the Getting started with Eclipse GEF online tutorial.

by Tamas Miklossy ( at June 25, 2019 08:00 AM

Eclipse Handly 1.2 Released

by Vladimir Piskarev at June 19, 2019 06:50 PM

Eclipse Handly 1.2 has just been released. This release is focused on further enhancements to UI components. Particularly, it provides a framework for creating a full-featured Call Hierarchy view.

New and Noteworthy
Migration Guide

by Vladimir Piskarev at June 19, 2019 06:50 PM

WTP 3.14 Released!

June 19, 2019 03:14 PM

The Eclipse Web Tools Platform 3.14 has been released! Installation and updates can be performed using the Eclipse IDE 2019-06 Update Site or through the Eclipse Marketplace . Release 3.14 is included in the 2019-06 Eclipse IDE for Enterprise Java Developers , with selected portions also included in 9 other packages . Adopters can download the R3.14 update site itself directly and combine it with the necessary dependencies.

More news

June 19, 2019 03:14 PM

Eclipse Introduces New IDE-Agnostic Tools for Building and Deploying Cloud-Native Applications

by Dustin Schultz at June 17, 2019 05:35 AM

Eclipse Codewind is a new developer-centric project from the Eclipse Foundation that aims to assist developers by providing ways to quickly and consistently accomplish tasks that are common to cloud-native application development.

By Dustin Schultz

by Dustin Schultz at June 17, 2019 05:35 AM

Eclipse Individual Committer Agreement 4.0 Update

by Sharon Corbett at June 14, 2019 03:27 PM

The Eclipse Foundation has been busy over the last six months communicating with the Community at Large in order to update our standard Contributor and Committer Agreements to state explicitly that contributions made to our projects may also be used in specifications.

Our second milestone in this campaign targeted the Eclipse Individual Committer Agreement (ICA) and we are happy to report that a very significant number of our individual committers successfully updated theirs.  On June 13th, we retired all versions of the ICA prior to version 4.0 which has placed a small number of individual committers in a temporary locked position.  Please note this does not impact your status as a Committer; it temporarily locks your commit privileges until the updated agreement is in place. This will ensure the integrity of all of our projects.

We are confident we have connected with all committers in this situation; however, we are here to help!  Email for assistance.

Thank you to the Eclipse Community for your support of this campaign and for helping make Eclipse a great community!

by Sharon Corbett at June 14, 2019 03:27 PM

My new book on TDD, Build Automation and Continuous Integration

by Lorenzo Bettini at June 12, 2019 04:59 PM

I haven’t been blogging for some time now. I’m getting back to blogging by announcing my new book on TDD (Test-Driven Development), Build Automation and Continuous Integration.

The title is indeed, “Test-Driven Development, Build Automation, Continuous Integration
(with Java, Eclipse and friends)
” and can be bought from

The main goal of the book is to get you started with Test-Driven Development (write tests before the code), Build Automation (make the overall process of compilation and testing automatic with Maven) and Continuous Integration (commit changes and a server will perform the whole build of your code). Using Java, Eclipse and their ecosystems.

The main subject of this book is software testing. The main premise is that testing is a crucial part of software development. You need to make sure that the software you write behaves correctly. You can manually test your software. However, manual tests require lots of manual work and it is error prone.

On the contrary, this book focuses on automated tests, which can be done at several levels. In the book we will see a few types of tests, starting from those that test a single component in isolation to those that test the entire application. We will also deal with tests in the presence of a database and with tests that verify the correct behavior of the graphical user interface.

In particular, we will describe and apply the Test-Driven Development methodology, writing tests before the actual code.

Throughout the book we will use Java as the main programming language. We use Eclipse as the IDE. Both Java and Eclipse have a huge ecosystem of “friends”, that is, frameworks, tools and plugins. Many of them are related to automated tests and perfectly fit the goals of the book. We will use JUnit throughout the book as the main Java testing framework.

it is also important to be able to completely automate the build process. In fact, another relevant subject of the book is Build Automation. We will use one of the mainstream tools for build automation in the Java world, Maven.

We will use Git as the Version Control System and GitHub as the hosting service for our Git repositories. We will then connect our code hosted on GitHub with a cloud platform for Continuous Integration. In particular, we will use Travis CI. With the Continuous Integration process, we will implement a workflow where each time we commit a change in our Git repository, the CI server will automatically run the automated build process, compiling all the code, running all the tests and possibly create additional reports concerning the quality of our code and of our tests.

The code quality of tests can be measured in terms of a few metrics using code coverage and mutation testing. Other metrics are based on static analysis mechanisms, inspecting the code in search of bugs, code smells and vulnerabilities. For such a static analysis we will use SonarQube and its free cloud version SonarCloud.

When we need our application to connect to a service like a database, we will use Docker a virtualization program, based on containers, that is much more lightweight than standard virtual machines. Docker will allow us to

configure the needed services in advance, once and for all, so that the services running in the containers will take part in the reproducibility of the whole build infrastructure. The same configuration of the services will be used in our development environment, during build automation and in the CI server.

Most of the chapters have a “tutorial” nature. Besides a few general explanations of the main concepts, the chapters will show lots of code. It should be straightforward to follow the chapters and write the code to reproduce the examples. All the sources of the examples are available on GitHub.

The main goal of the book is to give the basic concepts of the techniques and tools for testing, build automation and continuous integration. Of course, the descriptions of these concepts you find in this book are far from being exhaustive. However, you should get enough information to get started with all the presented techniques and tools.

I hope you enjoy the book 🙂

by Lorenzo Bettini at June 12, 2019 04:59 PM

Eclipse Tycho: Disable p2 dependency resolution with tycho.mode=maven

by kthoms at June 12, 2019 01:31 AM

In Eclipse Tycho based builds the first step is always computation of the target platform and depedency resolution. This takes quite some time and in certain use cases it is not necessary. Typical use cases are updating versions with the tycho-versions-plugin, or displaying the effective pom with help:effective-pom.

The p2 target platform & dependency resolution can be skipped by setting the tycho-mode system property:

mvn -Dtycho.mode=maven <goals>

This useful feature is a bit hidden in just a few posts, e.g.

by kthoms at June 12, 2019 01:31 AM

Inline Display of Error / Warning / Info Annotations in Eclipse

by Niko Stotz at May 26, 2019 10:11 PM

tl;dr: A prototype implementation shows all error, warning, and info annotations (“bubbles” in the left ruler) in Eclipse Java editor as inline text. Thus, we don’t have to use the mouse to view the error message. The error messages update live with changes in the editor.

Screencast showing the live effect

I’m an avid keyboard user. If I have to touch the mouse, something is wrong. Eclise has tons of shortcuts to ease your live, and I use and enjoy them every day.

However, if I had an error message in e.g. my Java file, and I couldn’t anticipate the error, I had several bad choices:

  • Opening the Problems view and navigating to the current error (entries in the Problems view are called “markers” by Eclipse)
  • Moving the mouse over the annotation in the left ruler (“annotation” in Eclipse lingo)
  • Guessing

Not so long ago, Angelo Zerr and others implemented code mining in Eclipse. This feature displays additional information within a text file without changing the actual contents of the file. Sounds like a natural fit for my problem!

I first tried to implement the error code mining based on markers, (Bug 540443). This works in general. However, markers are bound to the persisted state of a file, i.e. how a file is saved to disk. So they are only updated on saving.

Most editors in Eclipse are more interactive than that: They update their error information based on the dirty state of the editor, i.e. the text that’s currently in the editor. This feels way more natural, so I tried to rewrite my error code mining based on annotations. The current prototype is shown in above’s screencast.

The code is attached to Bug 547665. The prototype looks quite promising.

As above’s screencast shows, I have at least one serious issue to resolve: When the editor is saved, all code minings briefly duplicate. Thankfully, they get back to normal quickly.

by Niko Stotz at May 26, 2019 10:11 PM

Apache Camel development on Eclipse Che 7

by Aurélien Pupier at May 21, 2019 07:00 AM

Apache Camel development is improving on Eclipse Che 7 compared to Che 6. On Che 6, it is limited to XML DSL and without classical XSD-based XML support. With Che 7, Camel Java DSL is available and XSD-based XML support is working nicely with the Camel XML DSL support. Please note that Che 7 is still in beta.

Camel language features available

Inside the same editor, there is access to classic XML tooling and Camel XML DSL support.

Classic XML tooling completion based on XSD:
XMl tag completion based on Camel xsd

Camel XML DSL tooling completion:
Camel URI completion with Camel XML DSL

Classic XML tooling validation:
Validation based on Camel XML xsd

Camel XML DSL tooling validation:
Camel XML DSL validation of Camel URI

Inside the same editor, there is access to classic Java tooling and Camel Java DSL support.

Classic Java tooling completion:
Classic Java completion

Camel Java DSL completion:
Camel URI completion with Camel Java DSL

Classic Java tooling validation:
Classic Java validation

Camel Java DSL tooling validation:
Camel URI validation with Java DSL

How to configure on

Currently, some advanced steps are needed to have all extensions working together on a resource-limited Che environment, which is the default for Let’s see how to activate it.

  • Go to (you will have to register if you’ve not done so already).
  • Create a workspace based on Che 7.

Create Che 7 Workspace

  • Wait that workspace creation is finished.
  • Import the Camel/Fuse project that you want.
  • Go back to workspace configuration by using the top-left yellow arrow and clicking on Workspaces.

Go to workspace config

  • Click on the running workspace.
  • Click stop at the top right.
  • Go to Plugins tab.
  • Enable Language Support for Apache Camel, Language Support for Java and XML.

Enable Camel, Java and XML plugins

  • Go to config tab.
  • Search for “attributes”, add memory limits for each of the plugins, you should end with something like:
    "attributes": {
    "sidecar.redhat/java.memory_limit": "1280Mi",
    "sidecar.camel-tooling/vscode-apache-camel.memory_limit": "128Mi",
    "sidecar.redhat/vscode-xml.memory_limit": "128Mi",
    "sidecar.eclipse/che-theia.memory_limit": "512Mi",
    "editor": "eclipse/che-theia/next",
    "plugins": "eclipse/che-machine-exec-plugin/0.0.1,redhat/java/0.43.0,camel-tooling/vscode-apache-camel/0.0.14,redhat/vscode-xml/0.5.1"
  • Click on Open button on top right.
  • Open a Java file and wait that the Java Language Server has started (it can take several minutes).
  • Enjoy!

What’s next?

As you’ve noticed, the installation is currently a bit cumbersome as it requires you to touch the YAML config file. Don’t worry; there is work in progress to improve the installation experience, such as providing a specific Camel stack. This will allow you to create a workspace preconfigured, which means doing only the first three steps instead of the 11 steps of the configuration. Several other features are in the works by incorporating existing VS Code extensions inside Che 7. Stay tuned.


The post Apache Camel development on Eclipse Che 7 appeared first on Red Hat Developer.

by Aurélien Pupier at May 21, 2019 07:00 AM

I am an Incrementalist: Jakarta EE and package renaming

by BJ Hargrave ( at May 17, 2019 05:11 PM

Eclipse Jakarta EE has been placed in the position that it may not evolve the enterprise APIs under their existing package names. That is, the package names starting with java or javax. See Update on Jakarta EE Rights to Java Trademarksfor the background on how we arrived at this state.

So this means that after Jakarta EE 8 (which is API identical to Java EE 8 from which it descends), whenever an API in Jakarta EE is to be updated for a new specification version, the package names used by the API must be renamed away from java or javax. (Note: some other things will also need to be renamed such as system property names, property file names, and XML schema namespaces if those things start with java or javax. For example, the property file META-INF/services/javax.persistence.PersistenceProvider.) But this also means that if an API does not need to be changed, then it is free to remain in its current package names. Only a change to the signature of a package, that is, adding or removing types in the package or adding or removing members in the existing types in the package, will require a name change to the package.

There has been much discussion on the Jakarta EE mail lists and in blogs about what to do given the above constraint and David Blevins has kindly summed up the two main choices being discussed by the Jakarta EE Specification Committee:

In a nutshell, the two main choices are (1) “Big Bang” and (2) Incremental. Big Bang says: Let’s rename all the packages in all the Jakarta EE specifications all at once for the Jakarta EE release after Jakarta EE 8. Incremental says: Let’s rename packages only when necessary such as when, in the normal course of specification innovation, a Jakarta EE specification project wants to update its API.

I would like to argue that Jakarta EE should chose the Incremental option.

Big Bang has no technical value and large, up-front community costs.

The names of the packages are of little technical value in and of themselves. They just need to be unique and descriptive to programmers. In source code, developers almost never see the package names. They are generally in import statements at the top of the source file and most IDEs kindly collapse the view of the import statements so they are not “in the way” of the developer. So, a developer will generally not really know or care if the Jakarta EE API being used in the source code is a mix of package names starting with java or javax, unchanged since Jakarta EE 8, and updated API with package names starting with jakarta. That is, there is little mental cost to such a mixture. The Jakarta EE 8 API are already spread across many, many package names and developers can easily deal with this. That some will start with java or javax and some with jakarta is largely irrelevant to a developer. The developer mostly works with type and member names which are not subject to the package rename problem.

But once source code is compiled into class files, packaged into artifacts, and distributed to repositories, the package names are baked in to the artifacts and play an important role in interoperation between artifacts: binary compatibility. Modern Java applications generally include many 3rdparty open source artifacts from public repositories such as Maven Central and there are many such artifacts in Maven Central which use the current package names. If Jakarta EE 9 were to rename all packages, then the corpus of existing artifacts is no longer usable in Jakarta EE 9 and later. At least not without some technical “magic” in builds, deployments, and/or runtimes to attempt to rename package references on-the-fly. Such magic may be incomplete and will break jar signatures and will complicate builds and tool chains. It will not be transparent.

Jakarta EE must minimize the inflection point/blast radius on the Java community caused by the undesired constraint to rename packages if they are changed. The larger the inflection point, the more reason you give to developers to consider alternatives to Jakarta EE and to Java in general. The Incremental approach minimizes the inflection point providing an evolutionary approach to the package naming changes rather than the revolutionary approach of the Big Bang.

Some Jakarta EE specification may never be updated. They have long been stable in the Java EE world and will likely remain so in Jakarta EE. So why rename their packages? The Big Bang proposal even recognizes this by indicating that some specification will be “frozen” in their current package names. But, of course, there is the possibility that one day, Jakarta EE will want to update a frozen specification. And then the package names will need to be changed. The Incremental approach takes this approach to all Jakarta EE specifications. Only rename packages when absolutely necessary to minimize the impact on the Java community.

Renaming packages incrementally, as needed, does not reduce the freedom of action for Jakarta EE to innovate. It is just a necessary part of the first innovation of a Jakarta EE specification.

A Big Bang approach does not remove the need to run existing applications on earlier platform versions.  It increases the burden on customers since they must update all parts of their application for the complete package renaming when the need to access a new innovation in a single updated Jakarta EE specification when none of the other Jakarta EE specifications they use have any new innovations. Just package renames for no technical reason.  It also puts a large burden on all application server vendors. Rather than having to update parts of their implementations to support the package name changes of a Jakarta EE specification when the specification is updated for some new innovation, they must spend a lot of resources to support both old and new packages name for the implementations of all Jakarta EE specifications.

There are some arguments in favor of a Big Bang approach. It “gets the job done” once and for all and for new specifications and implementations the old java or javax package names will fade from collective memories. In addition, the requirement to use a certified Java SE implementation licensed by Oracle to claim compliance with Eclipse Jakarta EE evaporates once there are no longer any java or javax package names in a Jakarta EE specification. However, these arguments do not seem sufficient motivation to disrupt the ability of all existing applications to run on a future Jakarta EE 9 platform.

In general, lazy evaluation is a good strategy in programming. Don’t do a thing until the thing needs to be done. We should apply that strategy in Jakarta EE to package renaming and take the Incremental approach. Finally, I am reminded of Æsop’s fable, The Tortoise & the Hare. “The race is not always to the swift.”

by BJ Hargrave ( at May 17, 2019 05:11 PM

Create your first Quarkus project with Eclipse IDE (Red Hat CodeReady Studio)

by Jeff Maury at May 09, 2019 10:45 AM

You’ve probably heard about Quarkus, the Supersonic Subatomic Java framework tailored for Kubernetes and containers. In this article, I will show how easy is it to create and set up a Quarkus project in an Eclipse IDE based environment.

Please note that even if we use Red Hat CodeReady Studio in this article, any Eclipse IDE can be used assuming it has the tooling for Java-based development. So, you can also use the Eclipse IDE for Java Developers package or the Eclipse IDE for Enterprise Java Developers package.

Install IDE

If you don’t already have an IDE on your workstation, you must download and install one. You can use Red Hat CodeReady Studio or one of the Java packages from the Eclipse Foundation.

Once the IDE is installed, launch it and open a new workspace or reuse an existing workspace based on your preferences.

Create your first Quarkus project

Although it is possible from within the Eclipse-based IDE to create a Maven-based project using the new Maven project wizard, we will not use this path. It is based on the concept of Maven archetypes, and the Quarkus project does not provide a Maven archetype to bootstrap a new project but rather provides a Maven plugin to create a new project.

So, we will follow the Quarkus Getting Started Guide recommendation on how to bootstrap a Quarkus project.

Using a terminal, go into a folder where you want your first Quarkus project to be stored and type the following command:

mvn io.quarkus:quarkus-maven-plugin:create

You will be asked for the groupId for your project:

Set the project groupId [org.acme.quarkus.sample]:

Press the ENTER key to accept the default value.

You will be asked for the artifactId for your project:

Set the project artifactId [my-quarkus-project]:

Press the ENTER key to accept the default value.

You will be asked for the version for your project:

Set the project version [1.0-SNAPSHOT]:

Press the ENTER key to accept the default value.

Then, you will be asked if you want to add a REST endpoint in your application.

Do you want to create a REST resource? (y/n) [no]:

Enter yes and press the ENTER key.

Then, you will be asked for the class name of the REST endpoint.

Set the resource classname [org.acme.quarkus.sample.HelloResource]:

Press the ENTER key to accept the default value.

Then, you will be asked for the path of the REST endpoint.

Set the resource path [/hello]:

Press the ENTER key to accept the default value.

At this point, your first Quarkus project has been created on your local workstation, let’s import it into our IDE.

Import the first Quarkus project into IDE

From the IDE main window, open the File -> Import -> Existing Maven Projects menu:

Using the Browse button, select the folder where your first Quarkus project has been generated:

Press the Finish button, you should now see a new project in the Project Explorer window (please note that it may take a while, as Maven will download some Quarkus dependencies if this is the first time you have built a Quarkus project on your workstation):

Launch your first Quarkus application

From the Project Explorer window, select your Quarkus project (my-quarkus-project), right-click the Run As -> Maven build… menu:

In the Goals field, enter compile quarkus:dev:

Press the Run button. Your Quarkus application will start, and you should see the following output in the Console window:

At this point, your Quarkus application is started, and you should be able to access it from the following URL: http://localhost:8080/hello

Debug your first Quarkus application

Although Quarkus has nice hot reload capabilities for developers, debugging is a key tool. Let’s see how to set up debugging on our Quarkus application and then start a debugging session.

As you have probably noticed, we started the Quarkus application with the dev mode, which means that any changes in the application source code will be hot reloaded the next time your Quarkus application will process a request.

Another nice thing about the dev feature from Quarkus is that the Java virtual machine that is running the Quarkus application has been launched in debug mode. So, to debug our Quarkus application, we only need to connect a debugger.

If you’re familiar with the Java development tools in Eclipse, you know that you can easily launch a Java debugger against a running JVM that has been started in debug mode, assuming you know the debug port the JVM is listening on.

If you looked at your Quarkus application output, you noticed the following message:

This is the message generated by the JVM when running in debug mode, and it gives us the information that the port used is 5005.

Now you can create a remote Java debugger. Even better, because the message has been recognized by the Eclipse Java development tools, you just need to click on the list associated with the message and Eclipse will magically create a remote Java debugger and connect it to your Quarkus application!

After clicking on the hyperlink, you will see nothing because the remote Java debugger has been launched in the background and it connected to your Quarkus application. However, you can check it if you switch to the Debug perspective. To do that, open the Window -> Perspective -> Open Perspective -> Debug menu and select the Debug view. You should see something similar to:

As you can see, the debugger is connected to the Quarkus application. That means you can add breakpoints in your application source code and, next time you send a request, the Quarkus JVM will stop and the Eclipse IDE will step to the code in which you set a breakpoint.


The post Create your first Quarkus project with Eclipse IDE (Red Hat CodeReady Studio) appeared first on Red Hat Developer.

by Jeff Maury at May 09, 2019 10:45 AM

Eclipse Contributor Agreement 3.0

by waynebeaton at May 07, 2019 09:03 PM

The Eclipse Contributor Agreement (ECA) is an agreement made by contributors certifying the work they are contributing was authored by them and/or they have the legal authority to contribute as open source under the terms of the project license.

The Eclipse Foundation’s IP Team has been working hard to get the various agreements that we maintain between the Eclipse Foundation and community updated. Our first milestone targeted the ECA, and we’re happy to report that a very significant number of our community members have successfully updated theirs. Today, we retired all of the rest of them. Specifically, we’ve revoked all ECAs that predate the ECA version 3.0.

We’re confident that we’ve managed to connect and update the ECA for everybody who still wants to be a contributor, so there should be no interruption for anybody who is actively contributing. If we missed you, you’ll be asked to sign the new ECA the next time you try to contribute. Or you can just re-sign it now.

We’ve made some changes with the new agreements that make contributing easier, (but explaining harder). Committers who have signed the Individual Committer Agreement (ICA) version 4.0 or work for a company that has signed the Member Committer and Contributor Agreement do not require an ECA.

Contact if you’re having trouble with an agreement.

by waynebeaton at May 07, 2019 09:03 PM

Ways your company can support and sustain open source

by Chris Aniszczyk at April 30, 2019 01:49 PM

Note: this article was original posted on

To make sure open source continues to thrive, we all need to find ways to sustain the communities and projects we depend on

The success of open source continues to grow; surveys show that the majority of companiesuse some form of open source, 99% of enterprises see open source as important, and almost half of developers are contributing back. It’s important to note that companies aren’t contributing to open source for purely altruistic reasons. Recent research from Harvard shows that open source-contributing companies capture up to 100% more productive value from open source than companies that do not contribute back. Another research study concluded countries adopting modern open source practices saw:

“a 0.6%–5.4% yearly increase in companies that use OSS, a 9%–18% yearly increase in the number of IT-related startups, a 6.6%–14% yearly increase in the number of individuals employed in IT related jobs, and a 5%–16% yearly decrease in software-related patents. All of these outcomes help to increase productivity and competitiveness at the national level. In aggregate, these results show that changes in government technology policy that favor OSS can have a positive impact on both global social value and domestic national competitiveness.”

In the end, there are many ways for a company or organization to sustain open source. It could be as simple as training your organization to contribute to open source projects you depend on or hiring engineers to work on open source projects. Here are eight ways your organization can contribute back to open source, based on examples in the industry.

Hire open source maintainers to work on open source

Companies with strategies to leverage open source often find the highest returns from hiring a maintainer of the projects they depend the most on. It’s no surprise if you look at the Who Writes the Linux Kernel report that the top contributors are all employed by companies like ARM, Google, Facebook, Intel, Red Hat, Samsung, and more.

Having a maintainer (full time or part time) on your staff can help your organization learn how to work within the project community and enable prioritization of upstream contributions based on understanding of what the community is focused on. Hiring the maintainers also means that the project will have people with enough time to focus on the details and the rigor that’s needed for a project to be useful; think security reviews, bug cleanup, release management, and more. A more predictable and reliable upstream project can benefit many in your organization while also improving the overall project community. As a bonus, maintainers can also become advocates for your organization and help with recruiting too!

Develop an open source award program or peer bonus fund

It is common for companies to have internal employee recognition programs that recognize individuals who go above and beyond. As an example, Red Hat has a community award program through Some other companies have expanded their recognition programs to include open source contributors. For example, Google has an open source peer bonus program that recognizes external people who have made exceptional contributions to open source.

Start an open source program office

Many internet-scale companies, including Amazon, Google, Facebook, Twitter and more, have established formal open source programs (colloquially called OSPOs) within their organizations to manage open source strategy along with the consumption and contribution of open source.

If you want to increase your contributions to open source, research has shown that companies with formal open source programs are more likely to contribute back. If you want to learn from organizations with formal open source programs, I recommend you read the TODO Group Open Source Program Guides.

Launch an open source fund

Some organizations contribute fiscally to the open source projects that are important to them. For example, Comcast’s Open Source Development Grants “are intended to fund new or continued development of open source software in areas of interest to Comcast or of benefit to the Internet and broadband industries.” This isn’t just for big companies; small companies have open source funds, too. For example, CarGurus launched an open source fund and Eventbot is supporting open source with a small percentage of its company revenue. Another interesting approach is what Indeed has done by democratizing the open source funding process with its employees.

Contribute a portion of your company equity to open source

Consider donating a portion of your organization’s equity to an open source project you depend on. For example, Citus Data recently donated one percent of its equity to the PostgreSQL community. This worked out nicely; Citus Data was acquired by Microsoft recently, so the PostgreSQL community will benefit from that acquisition, too.

Support and join open source foundations

There are many open source foundations that house open source projects your organization depends on, including the Apache FoundationEclipse FoundationCloud Native Computing Foundation (home of Kubernetes), GraphQL FoundationLet’s EncryptLinux FoundationOpen Source Initiative (OSI), OpenStack FoundationNodeJS Foundation, and more.

Fund and participate in open source internships or retreats

There are many open source internship programs that you can participate in and help fund. Google Summer of Code (GSoC) is the largest, and it requires mentorship from employees who work on open source projects as part of the program. Or you can sponsor internships for underrepresented minorities in open source through Outreachy and CommunityBridge.

Another approach is to host an open source retreat at your company. For example, Stripe hosts open source retreats to contribute to open source projects it depends on.

Include open source in your corporate philanthropy initiatives

If your organization has a corporate sustainability or philanthropic arm, consider working with that team to include open source as a part of its work. For example, Bloomberg has a software philanthropy budget for projects it depends on, from Git to Eclipse to Python and more. In the future, I hope to see more corporate sustainability and philanthropy efforts—like Pledge 1%—that focus on funding critical open source infrastructure.


In conclusion, giving back to open source is not only the right thing to do, according to research, it’s also good for your business. To make sure open source continues to thrive and is sustainable in the long run, we all need to ensure that companies find ways to sustain the open source communities they depend on.

by Chris Aniszczyk at April 30, 2019 01:49 PM

Specification Scope in Jakarta EE

by waynebeaton at April 08, 2019 02:56 PM

With the Eclipse Foundation Specification Process (EFSP) a single open source specification project has a dedicated project team of committers to create and maintain one or more specifications. The cycle of creation and maintenance extends across multiple versions of the specification, and so while individual members may come and go, the team remains and it is that team that is responsible for the every version of that specification that is created.

The first step in managing how intellectual property rights flow through a specification is to define the range of the work encompassed by the specification. Per the Eclipse Intellectual Property Policy, this range of work (referred to as the scope) needs to be well-defined and captured. Once defined, the scope is effectively locked down (changes to the scope are possible but rare, and must be carefully managed; the scope of a specification can be tweaked and changed, but doing so requires approval from the Jakarta EE Working Group’s Specification Committee).

Regarding scope, the EFSP states:

Among other things, the Scope of a Specification Project is intended to inform companies and individuals so they can determine whether or not to contribute to the Specification. Since a change in Scope may change the nature of the contribution to the project, a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee.

As a general rule, a scope statement should not be too precise. Rather, it should describe the intention of the specification in broad terms. Think of the scope statement as an executive summary or “elevator pitch”.

Elevator pitch: You have fifteen seconds before the elevator doors open on your floor; tell me about the problem your specification addresses.

The scope statement must answer the question: what does an implementation of this specification do? The scope statement must be aspirational rather than attempt to capture any particular state at any particular point-in-time. A scope statement must not focus on the work planned for any particular version of the specification, but rather, define the problem space that the specification is intended to address.

For example:

Jakarta Batch provides describes a means for executing and managing batch processes in Jakarta EE applications.


Jakarta Message Service describes a means for Jakarta EE applications to create, send, and receive messages via loosely coupled, reliable asynchronous communication services.

For the scope statement, you can assume that the reader has a rudimentary understanding of the field. It’s reasonable, for example, to expect the reader to understand what “batch processing” means.

I should note that the two examples presented above are just examples of form. I’m pretty sure that they make sense, but defer to the project teams to work with their communities to sort out the final form.

The scope is “sticky” for the entire lifetime of the specification: it spans versions. The plan for any particular development cycle must describe work that is in scope; and at the checkpoint (progress and release) reviews, the project team must be prepared to demonstrate that the behavior described by the specifications (and tested by the corresponding TCK) cleanly falls within the scope (note that the development life cycle of specification project is described in Eclipse Foundation Specification Process Step-by-Step).

In addition the specification scope which is required by the Eclipse Intellectual Property Policy and EFSP, the specification project that owns and maintains the specification needs a project scope. The project scope is, I think, pretty straightforward: a particular specification project defines and maintains a specification.

For example:

The Jakarta Batch project defines and maintains the Jakarta Batch specification and related artifacts.

Like the specification scope, the project scope should be aspirational. In this regard, the specification project is responsible for the particular specification in perpetuity. Further the related artifacts, like APIs and TCKs can be in scope without actually being managed by the project right now.

Today, for example, most of the TCKs for the Jakarta EE specifications are rolled into the Jakarta EE TCK project. But, over time, this single monster TCK may be broken up and individual TCKs moved to corresponding specification projects. Or not. The point is that regardless of where the technical artifacts are currently maintained, they may one day be part of the specification project, so they are in scope.

I should back up a bit and say that our intention right now is to turn the “Eclipse Project for …” projects that we have managing artifacts related to various specifications into actual specification projects. As part of this effort, we’ll add Git repositories to these projects to provide a home for the specification documents (more on this later). A handful of these proto-specification projects currently include artifacts related to multiple specifications, so we’ll have to sort out what we’re going to do about those project scope statements.

We might consider, for example, changing the project scope of the Jakarta EE Stable APIs (note that I’m guessing a future new project name) to something simple like:

Jakarta EE Stable APIs provides a home for stable (legacy) Jakarta EE specifications and related artifacts which are no longer actively developed.

But, all that talk about specification projects aside, our initial focus needs to be on describing the scope of the specifications themselves. With that in mind, the EE4J PMC has created a project board with issues to track this work and we’re going to ask the project teams to start working with their communities to put these scope statements together. If you have thoughts regarding the scope statements for a particular specification, please weigh in.

Note that we’re in a bit of a weird state right now. As we engage in a parallel effort to rename the specifications (and corresponding specification projects), it’s not entirely clear what we should call things. You’ll notice that the issues that have been created all use the names that we guess we’re going to end up using (there’s more more information about that in Renaming Java EE Specifications for Jakarta EE).

by waynebeaton at April 08, 2019 02:56 PM

Eclipse Scout 9 release: out now!

April 05, 2019 05:07 AM

The official Scout version 9 has been released as part of the Eclipse simultaneous release 2019-03 and is now publicly available. In this article we highlight some of the new features such as improved responsiveness, support for OpenJDK and more.

With the Eclipse simultaneous release 2019-03, the new Scout version 9.0 has been released. As usual, it contains a lot of changes. We are happy to share some of the highlights with you. The complete release notes can be found here.

Support for OpenJDK and newer Java Versions

Long requested and finally here: Scout now supports running on OpenJDK, and on Java versions up to 11. Note that this requires a bit of work on the side of developers; and RedHat's OpenJDK version is not compatible out of the box due to missing elliptic curves. For more details, see the Java 11 section in the release notes and the migration guide.

Dark theme

You enjoy the dark theme of Eclipse, and want your Scout application users to enjoy the eye-friendliness of a dark theme too? Good news: A dark theme is now included with Scout and the widgets have been adjusted to blend in properly.

Improved Usability

To improve responsiveness if the window becomes narrow, group boxes can reduce their width by moving their field labels to the top automatically. The Scrollbar handles should be easier to catch, while the trees (treeboxes, navigation) scroll to show you a better view of your data when you expand or collapse an entry. Don't forget to check out the improved options for menu bars and how you can control what happens if there isn't enough space for all the menus.

Denser layout option

Sometimes screen space can be scarce and the generously spaced elements of Scout will show only a small amount of data in these instances. If you need to display more data at once, you can switch to the "Dense" layout, which reduces the amount of whitespace, which especially increases the number of table rows that are visible at the same time. Below you can see an example from our Contacts demo application:

New widgets: Mode Selector and Popup

Many widgets got small but awesome improvements – and for sure we have some new widgets too! For instances, check out the model selector and the popup widget.

Widget 1: Mode Selector

Similar to a Radio Button Group, the new Mode Selector allows you to switch between predefined options, but with a "regular button"-like interface that is quite common on smartphones.

Widget 2: Popup

With the new "Popup" (also known as popover on some platforms), you can display additional information in an overlay. You have many options to embed widgets here - we can't wait to see what you do with it!

The Popup has the following features:

  • Take any widget you like and open it in a Popup by using the WidgetPopup.
  • Use any widget you like as anchor and align the Popup around it.
  • Decide whether you want to point the Popup to the anchor by using the property withArrow.
  • Control the behavior of what should happen if there is not enough space to display the whole Popup using various properties.
  • Choose how the popup should react when the user clicks on the outside or on the anchor.

try out all the widgets in our widget app

Changed property lookup order

In many technologies such as Docker or Kubernetes, changing the configuration without having to create a new deployment is essential. To support this in Scout, the lookup order for Scout properties has been adjusted: It now allows overriding properties in the configuration file by using environment variables.

Get to know Scout?

Visit our project page, make your first steps with Scout using the comprehensive documentation, and check out the Scout forum if you have questions around a particular topic!

Scout survey

Do you have two minutes to make Scout even better?

Complete survey (2 MIN)

April 05, 2019 05:07 AM

New Release: Python<->Java Remote Services

by Scott Lewis ( at April 04, 2019 05:42 AM

There is a new release (2.9.0) of the ECF distribution provider for OSGi R7 Remote Services between Java and Python.

This release has:

An upgraded version of Py4j
An upgraded version of Google Protocol Buffers
Enhancements to the distribution provider based upon the improved Py4j and Protobuf libs

In this previous blog posting there are links to tutorials and examples showing how to use remote services between Python<->Java.

Python<->Java remote services can be consumed or implemented in either Java or Python.

by Scott Lewis ( at April 04, 2019 05:42 AM

Announcing Orion 20

by Mike Rennie at March 29, 2019 07:25 PM

We are pleased to announce the twentieth release of Orion, “Your IDE in the Cloud”. You can run it now at OrionHub, from NPM or download the server to run your own instance locally.

Once again, thank you to all committers and contributors for your hard work this release.

This release was focussed entirely on accessibility.

by Mike Rennie at March 29, 2019 07:25 PM

LiClipse 5.2.2 released

by Fabio Zadrozny ( at March 27, 2019 01:46 PM

This version does an updated of the main dependencies of LiClipse.

It's now based on:

  • Eclipse 4.11 (also named 2019-03)
  • PyDev (5.2.2) 
  • EGit (5.3.0)
As a note, it seems I haven't updated this blog as often as I should (I end up putting more effort into announcing the PyDev updates) but just to note, LiClipse is always updated whenever PyDev is updated.


by Fabio Zadrozny ( at March 27, 2019 01:46 PM

JFace TableViewer sorting via Drag and Drop

by Christian Pontesegger ( at March 25, 2019 12:31 PM

Recently I wanted to sort elements in a TableViewer via drag and drop and was astonished that I could not find  existing helper classes or tutorial for this fairly trivial use case. So here is one for you in case you got the same use case.

Source code for this tutorial is available on github as a single zip archive, as a Team Project Set or you can browse the files online.

If you are just interested in the helper class, have a look at DnDSortingSupport.


To have something to work on I will start with a TableViewer containing some data stored in a java.util.List. It is a default TableViewer and therefore I expect you have something similar ready for your experiments.

Step 1: Add drag support

Drag and Drop support for SWT is implemented via DragSource and DropTarget instances. To define that we can drag data, we need to bind a DragSource to a Control.
  DragSource dragSource = new DragSource(tableViewer.getControl(), DND.DROP_MOVE);
dragSource.addDragListener(new DragSourceAdapter() {

public void dragStart(DragSourceEvent event) {
event.doit = !tableViewer.getStructuredSelection().isEmpty();

public void dragSetData(DragSourceEvent event) {
if (LocalSelectionTransfer.getTransfer().isSupportedType(event.dataType)) {
LocalSelectionTransfer.getTransfer().setSelectionSetTime(event.time & 0xFFFF);

public void dragFinished(DragSourceEvent event) {

In line 1 we create the DragSource and define allowed DnD operations. As we want to sort elements, we only allow DND.MOVE operations. Then we define the way data gets transferred from the DragSource to the DropTarget. As we stay within  the same Eclipse application we may use a LocalSelectionTransfer.

The first thing that happens on a drag is dragStart(). Technically the selection cannot be empty as we have to select something before we start the operation, so this implementation is merely to understand how we could deny the operation right from the start.

After the drop operation got accepted in the DropTarget (see below) we get asked to dragSetData() and define what data we are moving. setSelectionSetTime() is not needed by our DropTarget, so again this is for completeness only.

Finally we need to clean up after the operation is done.

Step 2: Add drop support

Implementation is similar like before, just now we need a DropTarget. Instead of writing our own DropTargetListener we may use a ViewerDropAdapter which covers most of the required work already.
  DropTarget dropTarget = new DropTarget(tableViewer.getControl(), DND.DROP_MOVE);
dropTarget.addDropListener(new ViewerDropAdapter(tableViewer) {

public void dragEnter(DropTargetEvent event) {
// make sure drag was triggered from current tableViewer
if (event.widget instanceof DropTarget) {
boolean isSameViewer = tableViewer.getControl().equals(((DropTarget) event.widget).getControl());
if (isSameViewer) {
event.detail = DND.DROP_MOVE;
} else
event.detail = DND.DROP_NONE;
} else
event.detail = DND.DROP_NONE;

public boolean validateDrop(Object target, int operation, TransferData transferType) {
return true;

public boolean performDrop(Object target) {
int location = determineLocation(getCurrentEvent());
if (location == LOCATION_BEFORE) {
if (modelManipulator.insertBefore(getSelectedElement(), getCurrentTarget())) {
return true;

} else if (location == LOCATION_AFTER) {
if (modelManipulator.insertAfter(getSelectedElement(), getCurrentTarget())) {
return true;

return false;

private Object getSelectedElement() {
return ((IStructuredSelection) LocalSelectionTransfer.getTransfer().getSelection()).getFirstElement();

dragEnter() is the first thing that happens on the drop part of DnD. The default implementation is already fine. Our implementation additionally checks that the drag source is our current TableViewer. Further we disable the selectionFeedback. The feedback visually shows the user whether we drop before an element, on the element, or after it. The ViewerDropAdapter already supports these kind of feedbacks. Until bug 545733 gets fixed the helper class contains a small patch to provide before/after feedback only. It does not make sense to drop on another element when we do sorting, right?

validateDrop() will be queried multiple times. We might check that we do not drop the table element on itself, but we spared this check for the current example.

performDrop() finally implements the drop operation. To keep the helper class generic I used an interface that allows to insert elements before or after another element. An implementation of it needs to be passed to the helper class.

 public interface IModelManipulator {
boolean insertBefore(Object source, Object target);

boolean insertAfter(Object source, Object target);
The helper class comes with an implementation for java.util.List, which you may reuse.

by Christian Pontesegger ( at March 25, 2019 12:31 PM

Back to the top