Roadmap V2 has been superceded by Roadmap V3
As required by the Eclipse Development Process, this document describes the Eclipse Roadmap.
The Roadmap is intended to be a living document which will see future iterations. This document is the second version of the Eclipse Roadmap, and is labeled as version 2.0. In order to preserve this document while the underlying information evolves, the pages have been frozen by copying them from their original project hosted locations. Each frozen document is labeled with its version and date and includes a link back to its "live" version. Links that go outside this frozen copy are marked with the icon to inform the reader that that information may have changed since this document has written.
The goal of the Roadmap is to provide the Eclipse ecosystem with guidance and visibility on the future directions of the Eclipse open source community. An important element in this visibility is that the Roadmap determines what projects will be accepted by Eclipse during the life of this revision of the Roadmap. In other words, new projects must be consistent with the Roadmap. This does not mean that every new project must be explicitly envisaged by the Roadmap. It does mean that new projects cannot be inconsistent with the stated directions of Eclipse. In particular, Eclipse expects that incubator projects created in the Technology PMC will cover areas not explicitly described in the Roadmap.
There are four main sections to this document:
- This Preamble provides some background on Eclipse and the
Foundation, and identifies the strategic goals of Eclipse. It also
provides a brief overview of the scope of future projects anticipated
within the Eclipse open source community.
- The Themes and Priorities which has been
developed by the Eclipse Requirements Council.
- The Platform Release Plan which has been
developed by the Eclipse Planning Council.
- The Architecture Plan which has been
developed by the Eclipse Architecture Council
As defined on our website, the role of the Foundation is:
The Eclipse Foundation is a not-for-profit corporation formed to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.
As defined in our Bylaws the Purposes of the Eclipse Foundation are:
The Eclipse technology is a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools (the “Eclipse Platform”). Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself; Eclipse Platform tools are extensible in that their functionality is accessible via documented programmatic interfaces. The purpose of Eclipse Foundation Inc., (the “Eclipse Foundation”), is to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.
The following are the strategic goals of Eclipse.
- To define an open development platform which embodies technology leadership and innovation. As an open development platform, Eclipse provides support for multiple operating environments and multiple programming languages. The goal of Eclipse is to define for the industry a development platform and rich client platform (RCP) which is freely licensed, open source and provides support for the full breadth of the application lifecycle, in many disparate problem domains, across the development and deployment platforms of choice.
- To spur growth and adoption of Eclipse technology. Since its inception,
there has been rapid growth in people using Eclipse as their personal
toolset, as a platform for building their plug-ins, and as the basis for
their commercial products.
The high rate of adoption of the Eclipse technology can be traced to two key factors: great technology, and the ease with which it can be adopted by others, both commercial and open source. This ease of adoption has, in turn, several dimensions. The EPL and its CPL predecessor provide terms which are conducive to both commercial and open source use. The focus on extensible frameworks has made it relatively simple to re-use Eclipse Technology.
- To enable a commercially successful ecosystem. The creation of a large community of commercial and open source organizations which rely on and/or complement Eclipse technology has been a major factor in the success of Eclipse.
This is the second version of the Eclipse Roadmap document. It is important to recognize the many objectives which have been accomplished since the original version. The following is a list of accomplishments based on 2005’s themes.
- The Application Lifecycle Framework (ALF) project was created to focus on tool integration.
- Eclipse 3.1 startup time improvements, and support for large scale workspaces.
- CDT 3.0 parsing time improvements (ctags)
- Performance benchmarks being published
- A performance profiling and instrumentation infrastructure to help plug-in developers assess, root-cause, and fix performance issues.
- TPTP scales to handle large data volumes and process large number of transactions. EMF models for Common Base Event logs can now be persisted to database in addition to the flat XML file mechanism that existed earlier.
- Support for team policies and import/export of Ant build files in Eclipse 3.1.
- TPTP now supports tools for profiling, monitoring and testing distributed and multi-tier enterprise applications on a variety of operating systems and hardware.
- TPTP-based tool users can now collect data from target systems through firewall.
Design for Extensibility: Be a Better Platform
- Eclipse 3.1 made a number of improvements in this area:
- the programming model for contributing menu and toolbar items to the workbench was simplified,
- Support for generalized undo, and
- JDT made pushed several Java editor capabilities available in the platform text editor.
- TPTP introduced new public APIs to expose new capabilities present in major reimplementation of the data collection and communication frameworks.
- The Device Software Development Platform (DSDP) project was created as a top-level project designed to build this extensibility in a variety of areas, including enhancements in the Eclipse Debug platform, remote target management, J2ME development, and embedded GUI design in C++.
- The eRCP project is nearing its 1.0 release in the Technology Project.
- The CDT project focused on extensibility of the managed build system and scalability of the indexer for large embedded projects.
Rich Client Platform
- The Equinox project was created to provide additional focus on the OSGi component model within Eclipse.
- Support for using RCP with Java WebStart (JNLP).
- Support the ability to easily define a custom-branded application launcher.
- PDE enhancements to facilitate developing and deploying RCP-based applications, and for OSGi bundle manifest tooling.
- More control over the branding of RCP applications, including the changing of all filenames from eclipse has been addressed in 3.1.
Simple to Use
- Eclipse 3.1 provided enhancements to capabilities, Ant editing, improved initial user experience with Welcome content, and Help search.
- TPTP now enables a seamless import of existing JUnit tests. JUnit tests can edited either in source code or in TPTP graphical editor for test behavior. TPTP test tools ensure that test behavior model and corresponding source code are kept synchronized.
Enable Consistent Multi-language Support
- Several components common between CDT and Photran were identified. Photran now reuses these common components. As a result, improvements to any of these common components benefit both CDT and Photran.
Appealing to the Broader Community
- Eclipse 3.1 added support for J2SE 5 language features, including full support for development using the new language features, including code assist, quick fixes, new wizards, source actions, and refactorings.
- TPTP delivered on several initiatives to appeal to broader Eclipse community. TPTP enabled (i) Web application testing and profiling through integration with the Eclipse Java Development Tools (JDT) and Web Tools Platform (WTP) projects, (ii) report generation by integration with Eclipse BIRT project, and (iii) Eclipse GUI test automation tools through GUI event record and playback engine.
The goal of the Roadmap is to provide the Eclipse ecosystem with guidance and visibility on the future directions of the Eclipse open source community, and to involve the Eclipse membership in a dialog about those future directions. In that vein, this section discusses our current vision of the future as a set of future projects that expand the value of the ecosystem for all of its members.
The following diagram provides an architectural representation of the Eclipse technology today. The Architecture Plan goes into this in much greater detail.
The Themes and Priorities document prepared by the Requirements Council describes a number of requirements and focus areas for the existing Eclipse projects.
In addition to the Themes and Priorities requirements on existing projects in 2006, we envision future growth in Eclipse projects in the following major areas. These are areas in which we envision starting new projects in 2006, not areas in which we envision having completed Eclipse-quality standards-based frameworks and tooling.
- Extend coverage of the software development life-cycle
Eclipse today provides a great deal of coverage of the software development lifecycle. Eclipse’s goal is to provide complete coverage of the software development lifecycle with frameworks and extensible, exemplary tools. In 2005, major new initiatives were started to help extend Eclipse’s lifecycle coverage, including ALF, Data tools, and Modeling.
Some examples of possible new project areas which would further extend this lifecycle coverage include:
- requirements management,
- deployment, and
- system management.
In addition, Eclipse will continue to focus on evolving its frameworks and exemplary tools to meet new development technologies and runtime environments such as web services and service-oriented architectures. Support for additional programming languages is also anticipated.
- Extend the Rich Client Platform (RCP)
The RCP was first introduced by Eclipse with the 3.0 release of the Eclipse Platform in June, 2004. The RCP is a technology for building and managing applications with a rich user experience. Eclipse’s goal is to make the RCP a mainstream development and runtime platform for both ISVs and enterprise developers. To do so, we plan to evolve the RCP technology in the following ways:
- Target RCP for additional operating environments. One example of this is the eRCP project which is evaluating the use of Eclipse for embedded constrained devices such as mobile phones and PDAs.
- Enhance RCP with new functionality such as better update and management capabilities.
- Enhance the security capabilities of the RCP plug-in model.
- Provide application frameworks based on the RCP.
Eclipse has seen a great deal of success in the embedded marketplace over the past several years. For example, CDT has been used by a number of RTOS vendors as the basis for their tools platform. But there are many different technologies currently not covered by Eclipse which would extend to utility of the Eclipse Platform for the embedded market. Some examples include:
- Runtime analysis infrastructure to provide frameworks and tools to monitor applications running on a device
- Component configuration frameworks and tooling to configure operating systems, file systems and middleware
- Target connectivity frameworks to provide mechanisms to connect to embedded devices
- Hardware bring-up mechanisms for on-chip debugging and early development
- Board design tools
- Multiple language support
Although Eclipse has been very successful in providing language tools for Java and C/C++, doing so still requires a great deal of effort. Improving the Eclipse frameworks to provide more consistent APIs for plugging in editors, debuggers, build environments, etc. for multiple languages is an important goal. There are several different views on what multiple language support can mean. Support for compiled languages, scripting languages and "Java like" languages such as JSP, SQLJ and the like are all related areas where work needs to be done. There are numerous trade-offs to be made as well. For example, JDT has been highly customized to provide a very rich feature set. Will an abstract language toolkit approach meet its needs?
From the perspective of the plug-in providers, there is a lot of interest in more easily enabling plug-ins for specialized components (debuggers, managed builds, editors) which work across multiple languages. Currently if an add-in provider wants to support both CDT and JDT separate plug-ins are required.
- Vertical market technology frameworks
We are seeing interest from vertical market vendors in basing their next generation tools on Eclipse. Thus a future growth area for Eclipse is to extend our projects to provide open source application frameworks and exemplary tools targeted at standards in specific vertical markets such as aerospace, automotive, and healthcare.
The process of creating the Eclipse Roadmap is described in the Eclipse Development Process. The key pieces are
Creating or updating the Roadmap begins with the Requirements Council proposing a set of Themes and Priorities that realize the Purposes and that respond to requirements elicited from the Strategic Developers, Strategic Consumers, Add-in Providers, and other constituents of the Ecosystem. After review by the Board of Directors, these Themes and Priorities are provided as input to the Architecture Council and the Planning Council. The EMO ensures that the Planning Council and the Development teams have access to all requirements. Updates to the Purposes are likely to require updates to the Roadmap and its associated themes and priorities; proposed Roadmap updates may also be motivated by new technologies or opportunities.
The process of producing or updating the Roadmap is expected to be iterative. An initial set of Themes and Priorities may be infeasible to implement in the desired timeframe; subsequent consideration may reveal new implementation alternatives or critical requirements that alter the team’s perspective on priorities. The EMO orchestrates interaction among and within the three Councils to drive the Roadmap to convergence.
This first version of the Eclipse Roadmap has been developed by the three councils: the Architecture Council, the Planning Council and the Requirements Council. The three Councils met face-to-face three times in 2005: once in May, once in September and again in December. (The minutes of these meetings are available on the Councils page. Subsequent discussion of the Roadmap was done through numerous individual phone calls, and more numerous emails amongst the Council members.
The information flow we managed to achieve in this first draft was:
from the membership (both the membership-at-large and the strategic members) to the Requirements Council
from the Requirements Council to the Planning and Architecture Councils
from the PMC project plans to the Planning Council
from the PMC architecture plans to the Architecture Council
In summary, through lots of hard work by everyone, the three groups converged on this Roadmap document.
The Roadmap was presented and affirmed by the Eclipse Board of Directors on Monday, March 20, 2006.