Eclipse is… Open Source Projects
Eclipse is… Open Source Projects
Join the DZone community and get the full member experience.Join For Free
Microservices. Streaming data. Event Sourcing and CQRS. Concurrency, routing, self-healing, persistence, clustering...learn how Akka enables Java developers to do all this out of the box! Brought to you in partnership with Lightbend.
One of the great things about Eclipse is that–unlike the celestial event and the unfortunately-named movie–everybody gets to see it; regardless of your location on earth, you have access to Eclipse.
But, like Linus, some people are confused as to the nature of Eclipse. To try and help people better understand Eclipse, I’ve created a “What is Eclipse?” talk that takes an audience step-by-step from what is commonly understood through a voyage of discovery of the true greatness of Eclipse. More specifically, I start by introducing Eclipse as a Java IDE. This is generally easy for the sorts of audiences that I speak with to understand: folks in the software industry understand IDEs (though there are still a few emacs hermits out there; and I mean “hermit” in a wholly-endearing way). I spend the next couple of slides broadening the technical horizon by introducing Eclipse as a platform for building IDEs, tools, desktop applications, server applications and runtimes, and more.
All this technology is wonderful. But technology is only part of the Eclipse not-so-secret sauce. All of that technology comes from the many open source projects at Eclipse.
We have a lot of projects at Eclipse. A lot of projects. Up to this point in the presentation, most of the discussion has been around just a small handful of projects. The “Eclipse” Project is responsible for creating most of what people think of when they think of Eclipse. Specifically, the Eclipse Project creates what we try very hard to consistently refer to as the “Eclipse SDK” (that is, a software development kit for building Eclipse-based applications). The Eclipse Project leverages the work of several other projects (Equinox comes immediately to mind) to provide important bits of information, but most of the bits that people think of when they think “Eclipse is a Java IDE” comes from the Eclipse Project.
Now this is where things start to get a little weird. The Eclipse Project is what we call a “Top-Level Project”. It is–effectively–a container for several smaller-scale projects. Each of these smaller scale projects, often referred to as simply “projects” or “subprojects”) is a distinct entity that contributes parts to the greater whole. The Platform Project, for example, produces the UI, workbench, and many other fundamental services and frameworks; the Java development tools (JDT) project produces the Java compiler, editors, debugger, and such; the Plugin-Development Environment (PDE) produces tools to aid in the construction of plug-ins; and more. All these Projects have distinct development teams, web sites, and other resources.
The Eclipse Project is just one of the top-level projects at Eclipse. There are currently twelve top-level projects that organize dozens of projects. Top-level projects provide more than simple organization of projects. Each top-level project has a “Project Management Committee” (PMC) that is responsible for providing oversight and guidance to the projects in their care. Each top-level project is a little different from the others, reflecting different values and technical areas. Some top-level projects tightly organize their projects; others allow greater levels of flexibility.
The fact of the matter is that we have a heck of a lot of projects at Eclipse. At last count we had more than 250 projects (I can hear you gasp at that number). The project is the finest-grained organizational unit at Eclipse. Each project has its own group of developers (called “committers”), its own website, forums, mailing lists, source code repositories, downloads and more. Some projects provide aggregations of other projects; a project can, for example, have subprojects of its own.
It’s left to the project teams to decide how they want to organize. Typically, mid-level projects tend to be used to provide some hierarchical organization for related projects. Very often mid-level projects (and top-level projects in some cases) provide handy aggregate builds and downloads of the software produced by the projects they contain. The Web Tools Platform Project, much like the Eclipse Project, is a good example of this. Web Tools contains multiple separate projects (e.g. Dali and EJB Tools), but distributes downloads and updates under the top-level project. As an outsider-looking-in, Web Tools comes across as a single source of software (the fact that it is really multiple projects under the covers is a bit of an implementation detail).
So anyway… we have a lot of projects. They’re organized under top-level projects that provide oversight and guidance. Chances are very good that we have something going on at Eclipse that interests you.
But Eclipse is more than just technology and projects. Eclipse is… a Community.
Opinions expressed by DZone contributors are their own.