The Background of TEA

Before I delve into the nuts and bolts of extending the Eclipse IDE, let’s look at the origin of Eclipse TEA.

A few years ago, in the good old days of Apache Ant,³ we were engineering a large-scale logistics application. For various reasons, Eclipse RCP⁴ was chosen as this application’s platform. Even for server-side applications, we used the exact same setup, except without the UI parts of Eclipse RCP. This application was extremely large; it had roughly six million lines of code and was composed of approximately 650 OSGi⁵ bundles.

In order to maintain metadata, such a huge application required heavy lifting by both Eclipse and the developers’ hardware (at that time), and the developers themselves.

When taking into account the build system (Apache Ant) for headless builds (in other words, running a build without any UI and usually running on a server without a monitor attached in the first place), we understood the need for very lengthy and hard-to-maintain build XML files. Additionally, there were dozens of property files containing plug-in and feature versions to build and to include in update sites.

As a consequence, we had literally weeks where not a single nightly build succeeded even though workspaces in the IDEs of the developers were OK all along, meaning that builds and tests were successful. They just forgot to maintain the additional metadata (or did it wrong unknowingly). Developers never even had a chance to test nightly builds because they required a very special setup that was nearly impossible to reproduce on individual workplaces.

Eclipse does allow adding additional builders per project, but this is not what we wanted. We required some orchestration on top of the normal build process since the generators had multiple source projects, multiple input projects, and multiple output projects.

In the IDE, the developer performed this orchestration. Usually, Eclipse performed the automatic build until the first bits were compiled. (In this state, the workspace was basically full of compile errors due to missing generated code in all other projects.) Now generators could be run manually to provide the next bits of code to compile. This process was repeated until all generators had been run—a tedious job. In the headless builds , there were Apache Ant scripts, which basically did the same. Due to frequent changes in projects setups (new, removed, renamed projects, and so on), these scripts were basically always out of sync with reality.

Things continued this way until some developers had enough. They had the idea to provide some automation to the most annoying steps in the process, along with simplifying headless setups. This was the birth of WPoB—short for WAMAS (the product’s name) Power Build. It was later rewritten and rebranded as Eclipse TEA.

TEA Is Born

Initially, TEA was basically a wrapper and tiny orchestrator around the IProject.build() method , already provided by Eclipse. Thus, anything hooked on the default Eclipse mechanism for extending the build worked out of the box, but TEA was able to provide the additional orchestration on top.

As a positive side effect, which was discovered during implementation, a remarkable performance gain occurred once the first version of TEA was able to build our workspace. As of the time of writing, developers use the TEA mechanisms to build the workspace instead of the automatic build in case there are a lot of changes to be compiled—for instance, when updating the workspace with a lot of changes from the source repository.

The reason for this performance gain (today it is not as huge as it was back then) was traced back to the fact that Eclipse does not have an orchestration on top of the individual project builds. Eclipse has a build order for the workspace that may be good—but may be just as bad. The developer can manually set up the order, or it can be left up to Eclipse to calculate it (which is the default). Eclipse accounts for multiple factors when trying to figure out a build order such as project dependencies and references. In our case, it seemed to come up with a rather bad order that resulted in Eclipse running in circles trying to compile certain projects over and over again, although their prerequisite projects were not yet compiled. Along with our generators, which interrupted the build process multiple times along the way, there was no chance to find a good ordering any way in the first place.

Eclipse TEA’s build library does not have this problem. It adds an orchestrator that calculates a graph up front, allowing for manipulating and influencing this graph. Other than Eclipse’s build order, this graph cannot be influenced by configuration of Eclipse. However, it can be extended and manipulated via code. I will provide a detailed description of this mechanism later in this book.

But there is more. Looking at the current open source Ecosystem, reading mailing lists, and so on, you will likely discover mails discussing how to prevent the fact that certain ways of working break things for others working in a different way. For example, projects where half the developers use Eclipse and the other half does not fall into this category. Headless builds are also usually performed without Eclipse (they are rather performed by tools like Apache Maven,⁶ Gradle,⁷ and so on), so the ones avoiding Eclipse all together might easily break things for the others. In this case, it can help to have an additional build performed using Eclipse, which is a simple task using Eclipse TEA.

What I have described so far is actually only an optional part of today’s Eclipse TEA (called “Eclipse TEA build library”). The core of TEA was a byproduct of our initial efforts to get the builds, as previously described.

To be able to encapsulate the individual steps of the builds (building, generating code, and so on), a rudimentary task-based execution engine was implemented. It had the capability to execute a TaskChain, which configured a series of certain Task objects to be executed. The concepts of Task and TaskChain are at the heart of TEA and are mentioned in all of the subsequent chapters.

Building upon these concepts, we implemented the things we wanted to perform in the IDE or in headless environments as tasks. This implementation paid off more than once because it was easy to reuse tasks in headless environments.

The Current State of TEA

Now that I have told you what is possible, I must inform you that not all of this is (yet) in the open source Eclipse TEA. A lot of this code is still closed source (but there is the intention to open source everything which is not too specific to the company—meaning everything that does not hard code concepts of the software we are building).

I include it here so you can get a picture of what is feasible to be implemented using Eclipse TEA.