Great Fixes from Eric Williams

Updating to GTK3 has been a bit of a challenge. While researching this problem earlier this year, I ran across countless blog posts, and forum comments from all sorts of open source project teams that were frustrated with their own efforts to update to GTK. Some had starting making plans to just abandon it, but that’s just not a realistic option for the Eclipse Platform.


Getting our GTK3 binding running well was selected by the Eclipse Architecture Council as the highest priority work item for the Friends-Enabled Eclipse IDE/Platform Enhancements Program (FEEP): we allocated some development funds for it last year, but finding the right combination of skills and experience to complete the work has been challenging. That is, until the team from Red Hat stepped up.

Red Hat developers (along with others from IBM and Ericsson) have been steadily improving the implementation for a couple of years, but the bulk of the work has been done in the last year with the majority of the commits coming from third-year Computer Science undergraduate student, Eric Williams.

Eric is working at Red Hat in a sixteen month co-op (intern) programme as part of the University of Toronto’s Professional Experience Year (PEY). He returns to school in September 2016 to finish his last year. Eric credits his managers Alexander Kurtakov and Martha Benitez, and mentor Leo Ufimtsev (Alexander and Leo are Eclipse SWT committers) for getting him set up to make real contributions to a thriving open source project and providing what he calls a “fantastic experience”.

In recognition of his efforts, Eric was asked by the SWT project team to join them as a committer; happily, he’s accepted the nomination. In appreciation for his Great Fix contributions, we’re sending Eric a Samsung Galaxy S6.

The Great Fixes Candidates page shows a list of the commits attributed to Eric, along with those of the other Great Fix candidates.

Posted in Announcements, Great Fox, Neon | Leave a comment

Great Fixes for Neon

Great Fixes for Eclipse Neon is a skills competition. Flex your Eclipse development skills for an opportunity to win prizes and acclaim!

A Great Fix is a contribution provides a significant improvement in projects participating in the Eclipse Neon Simultaneous Release, with a particular focus on projects that contribute to the desktop Eclipse IDE experience.

This competition has been in progress since June 2015: if you’ve submitted a patch that’s been accepted, then you’re already on the pool of potential winners. It’s not too late to join. The final deadline to have your patches accepted is May 26/2016, but the effective deadline for many projects is the Eclipse Neon M7 milestone date (after M7, most projects will only accept critical fixes; check with the project team).

To enter, all you need to do is a submit one or more patches. All contributions that are accepted by the corresponding project team and merged into the project code base before the deadline automatically qualify.

To qualify for consideration as a Great Fix, a contribution must:

  • Be for a project that is participating in the Eclipse Neon Simultaneous Release;
  • Be submitted between June 24/2015 and May 26/2016;
  • Be submitted by a non-committer;
  • Be accepted by a project committer and merged into the corresponding source code repository; and
  • Be deemed “significant” by the Architecture Council.

Fixes may be considered individually or in groups. Priority will be given to fixes that address the issues identified as high-value by the Architecture Council or otherwise improve the desktop IDE experience. Members of the Architecture Council are excluded from winning.

We’ve set up a page that lists all of the candidates based on a query against our Git commit index. Note that this list is provided for informational purposes only and that it may contain errors due to limitations in the underlying data. It will be used as input into the process.

Prizes are Android devices. There will be ten winners.

The Architecture Council will start picking weekly winners out of the pool on April 15th.

Posted in Uncategorized | Leave a comment

Quick Access to Eclipse IDE Features

As Lars points out on the ide-dev mailing list, a lot of Eclipse IDE users aren’t aware of some very handy features, especially the one-feature-to-rule-them-all: Quick Access.

In an Eclipse IDE, Quick Access will take you quickly to the feature you need. To activate Quick Access, type Ctrl+3 and start typing (or click in the entry field in the toolbar and start typing).

Screenshot from 2016-04-06 15-24-27

Quick Access will find and list all of the features that match what you type, including commands, views, editors, menus, preferences, and perspectives. Selecting an entry will take the appropriate action for whatever is selected (e.g. invoke the command or open the preferences page).

Note that if they exist, the list of available features will include key bindings. You get at the full list of key bindings (Key Assist) by typing Ctrl+Shift+L.

I’m not sure what the key bindings for Quick Access or Key Assist are on the Mac, but if you’re using a Mac, start typing in the Quick Access toolbar field to find out…

Posted in Eclipse 101, Screenshots | 10 Comments

Just Drag and Drop to Install

The Eclipse Marketplace is a pretty cool bit of software. It provides a great place for organizations and individuals to make their software available to the community. Even cooler, however, is the Eclipse Marketplace Client which lets you browse the Eclipse Marketplace and directly install new features from within the comfort of your Eclipse IDE.


The Eclipse Marketplace Client is included in all of the products hosted on the Eclipse Downloads page and configurations realized by the installer. Open the Marketplace client via the Help > Eclipse Marketplace… menu.

I’ll admit, however, that I rarely use the Marketplace Client directly. Instead, I make use of the drag and drop feature.

Eclipse Marketplace entries have a handy “Install” button:


If you drag this button from your web browser and drop it on your Eclipse IDE, it will start the installation process. You’ll have to review the changes that it proposes and likely agree to licensing terms, but after that, it all just happens. You don’t to fuss with software source (p2) sites: it just works.

The best part is that you can include those handy install links on your own web pages. Every Marketplace entry has an “External Install Button” tab that gives you the HTML to insert onto your page.

Do you miss having CVS integration in your IDE? You can install it right now:

Drag to your running Eclipse workspace to install CVS Integration

Do you need a German language pack for your Eclipse IDE? Drag and drop this und Eclipse sprechen Ihre Sprache:

Drag to your running Eclipse workspace to install Eclipse IDE Language Pack:  Deutsche

Or maybe install the Docker integration:

Drag to your running Eclipse workspace to install Eclipse Docker Tooling

For users, it couldn’t be easier to extend your Eclipse IDE in all sorts of ways.

For Eclipse Project teams, the Eclipse Marketplace is a great way to help people get and use your software. When you create a marketplace entry that pulls software from the Eclipse downloads server, that entry is automatically added into the Eclipse Project Market and is given the Eclipse Project badge.

When you’re blogging about the cool new features in your latest release, why not include a handy install button?

Posted in Eclipse 101, Screenshots | Leave a comment

Releases and the Eclipse Development Process

The Eclipse Development Process (EDP) regards a release as a pretty significant event. A release is similar to what other organizations might call a general availability release (GA), or ship event. A release is generally associated with some form of enhanced quality assurance testing and marketing. A release is intended for the widest possible audience of users, adopters, and downstream consumers. How often these events occurs varies from open source project to project: some projects release annually and others release more frequently. Some open source projects don’t release at all (I tend to think of these projects as potential candidates for termination; but I’ll save that discussion for another day).

The EDP goes to painful lengths to avoid using the word release in any sense other than the aforementioned significant event, referring instead to various types of builds with an implication that these builds are made available for download by target audiences.

Nightly builds—as the name suggests—are the product of an automated build process that runs every night. Nightly builds often break automated tests. They are intended primarily for testers and developers, and are not inappropriate for general consumption. Nightly builds are short-lived, remaining accessible for a few days at most.

Integration builds are created less frequently than nightly builds; the EDP makes no specific requirement regarding how often these are created, but many projects generate weekly integration builds. A lot more care is taken to ensure that integration builds do not break tests. Integration builds tend to target a slightly larger audience, e.g. adopters and other downstream development teams. Like nightly builds, integration builds are short-lived; project teams typically keep a small number of the most recent integration builds accessible at any time.

Milestone builds are a bit more of an event. They pass all automated tests and are intended for a much broader audience of bleeding edge users and adopters. The primary intent of issuing a milestone build is to solicit feedback on an upcoming release (milestone builds are tied to a future release). The cadence for milestone builds varies by project. The annual simultaneous release does seven milestone builds and three release candidates (the EDP regards milestone and release candidate builds as equivalent). The pace is one milestone build every six weeks with release candidates coming more frequently in the weeks leading up to the release.

Releases come in three different flavours: major, minor, and service. A major release indicates that major changes, including API breakage or including significant new functionality. A minor release introduces new functionality, but maintains backwards compatibility with the previous release. A service release includes bug-fixes only and—like a minor release—is backwards compatible.

As a service to the community (and in order to conform to the EDP), releases and builds must be consistently labelled.

Release names follow a common three-digit version numbering scheme: x.y.z indicating a major, minor, and service number. Note that the release name does necessarily need to be reflected in the technical implementation. A hypothetical zip-file download would carry the name of the release, but may contain (for example) OSGi bundles with a variety of different version numbers (i.e. only rev the version number of individual bundles as is required for technical reasons). Trailing zeros are optional.

Milestone build names leverage the name of the release that they’re tied to and are indicated with either an “M” or an “RC” in the form x.yMn (e.g. 3.8M2 or 3.8RC1 are milestone builds for a future 3.8.0 release).

Integration builds should take the form “I<date>-<time>” (e.g. I20160216-0800); nightly builds take a similar form, but with an “N” prefix. Note that our mirroring process uses this naming convention to limit the propagation of integration and nightly builds to our mirrors (the full exclude list is captured in the IT Infrastructure FAQ).

The frequency and types of builds that a project creates leading up to a release varies widely and is dependent on numerous variables, many of which are specific to (and best known by) the project team. The Eclipse Foundation expects that project teams know their community and consumers and work with them to sort out the best strategy.

Note that we’ve created a new incubation mailing list specifically for new project teams to pose questions to their peers and the Eclipse Architecture Council. This is the best possible place to ask questions about process.

EclipseCon NA 2016

Posted in Community, EDP, Project Management | 1 Comment

Swing by to Talk about SWT and JavaFX

Eclipse SWT support for GTK3 has improved dramatically since the Eclipse Mars release: the latest milestone and nightly builds work and look great on my Fedora 22 box. There’s still some work to do, but the progress since Mars is impressive. Fixing SWT/GTK issues requires a special set of skills: if you have those skills, you might find our work item to Improve GTK 3 Support interesting.

Or, if you just want to see how you can help, drop by the EclipseCon 2016 Hackathon and we can try and hammer out a fix or two together. A few actual Eclipse Platform committers will be at the conference, so I’m using “we” in the royal sense.

If JavaFX is more to your tastes, consider attending the two EclipseCon sessions being lead by the Eclipse community’s JavaFX expert and Eclipse e(fx)clipse open source project lead, Tom Schindl: Develop Slick Rich Client Applications with Eclipse 4 on JavaFX, and Smart, slim and good looking – Building Smart Editors with Eclipse and JavaFX.


EMF Edit UI for JavaFX allows you to view your EMF models in JavaFX TextFields, ListViews, TreeViews and TableViews with only a few lines of code.
(from the project website)

Tom can help you get started building JavaFX applications using Eclipse; he’s also the best person to help you build Eclipse Rich Client Platform applications, editors, and IDEs with JavaFX as a base.

You can also learn about some fascinating work being done in the Eclipse Integrated Computational Environment (ICE) project in the form of Adventures in 3D with Eclipse ICE and JavaFX (ICE leverages the JavaFX/SWT integration layer, FXCanvas). Speakers Tom McCrary and Robert Smith, as members of our Science Working Group, are involved in some very cool new work being done at the Eclipse Foundation.


Alex McCaskey and project lead Jay Billings running ICE on ORNL’s EVEREST Powerwall
(from Jay’s post from July of last year).

See you at EclipseCon!

EclipseCon NA 2016

Posted in EclipseCon, Hackathon, Java | 2 Comments

Connect with Eike Stepper at EclipseCon 2016

If you need to get a development environment configured just right and share that configuration with your team, you need to connect with Eike Stepper, the project lead and resident expert on our awesome (Oomph-some?) Eclipse Installer technology.


The Eclipse Installer technology, based on Oomph, excels at doing very simple sorts of installations, like pulling together and assembling the pieces of the Eclipse IDE for Java Developers. But that only scratches the surface: you can build and share a script that realizes a complete development environment that includes extra plug-ins, clones of your Git repositories, tasks from your issue tracker, specific workspace preferences configurations, and more. The Eclipse Oomph Installer Technology can get your developers up and running in a matter of minutes.

Eike will cover Oomph topics during the conference: he’s hosting a tutorial and a talk with Ed Merks. Frankly, I can’t say enough good things about Ed and Eike: just spending a few minutes in their proximity will make you smarter. Eike is also presenting some exciting updates to the very cool Eclipse Connected Data Objects (CDO) technology.

You’ll have a chance to work directly with Eike at the EclipseCon 2016 Hackathon on Wednesday, March 9 from 11:15 to 11:50 am.

EclipseCon NA 2016

Posted in EclipseCon | Leave a comment