Eclipse Themes and Priorities
This document captures the inputs to the Eclipse Requirements Council as
of this date. The inputs are from three major sources:
- Strategic Members of the Eclipse Foundation,
- the Project Management Committees (PMCs), and
- the general membership through the input collected from various
The themes were generated by collecting requirements from the above
sources and then synthesizing themes from the various inputs.
back to top
These are our fundamental principles, which span all of the themes
- Eclipse projects provide exemplary (meaning "show by example") implementations and extensible frameworks. Where projects require use of other technolgies (such as source control, application servers, build engines), they will target exemplary free open source implementations of those technologies."
- We will aim for release-to-release binary compatibility for API
clean plug-ins for at least the last major release.
- The platforms supported by each project are determined by the
specific project. Each project must keep its support for all supported
platforms current and publicly announce otherwise.
- The Eclipse community will relentlessly re-factor code to improve
components and make them available for public consumption.
back to top
Themes and Priorities
These themes are not in priority order.
This refers to the need for Eclipse to deal with development and
deployment on a larger and more complex scale. Increasing complexities
- large development teams distributed in different locations,
- large source code bases, large amounts of data,
- multiple scripting and programming languages,
- complex build environments that have been developed incrementally
- the dynamic nature of new source code bases and their interaction
with configuration management, and
- build environments involving many different tool chains and build
- Performance improvements in memory footprint, user perceived
response times, and start-up times as the complexity and number of
projects, files, users, and plug-ins grow (10X-100X over the next two
years). This is particularly important in client/server environments
where a single Solaris, AIX, Linux or HP-UX server must support dozens
of concurrent Eclipse users and where Eclipse competes mostly with
command line tools.
- Further reduce memory footprint
- Improve support for and performance with Motif based window
managers on Solaris (drag and drop, etc)
- Improve remote X window performance
- Improve performance when creating, loading, importing and closing
projects with slow file systems (networks)
- All Eclipse projects should identify common use cases and publish
performance benchmarks on every milestone.
- The projects are encouraged to develop APIs that exploit multi-core
/ multi-threaded and 64-bit addressing capabilities of underlying
processors. This will enable the Eclipse eco-system to deliver superior
- Ability to deal with extremely large projects and workspaces where
there is a large number of developers working on different, and
sometimes overlapping parts of the source tree simultaneously. This may
include a more efficient way to manage multiple workspaces. Examples of
large projects include Mozilla and Open Office.
- Improve the Eclipse project and workspace concept to allow
- Ability to fit into an existing environment of source files, build
artifacts and version control repositories with minimal disruption to
let developers complete a full edit-compile-debug cycle in the shortest
possible time. This may include better support for multiple programming
languages across *DTs for improved usability. This would also include a
more flexible project model.
This theme discusses changes to Eclipse to ease adoption by large
development organizations. As the size of a development organization
grows, the manner in which an organization as a whole uses Eclipse
changes. For example, emphasis shifts to manageability, maintainability,
and support for various Eclipse versions. Here are the requirements to
ensure that Eclipse can be used well in a large enterprise.
- Enable Eclipse and Eclipse based applications to be managed
- Support pushing a core set of features to be installed and be
visible on Eclipse deployments throughout the enterprise. This is
complementary to the pull model inherent in the update manager
- Provide ability for installed features / capabilities to be
centrally managed / reported at the team / department level, and
managed by an enterprise for its users.
- Deployment: We need to support changes to Eclipse to enable
deployment of Eclipse based applications across the enterprise. This
includes monitoring capabilities, enhancing of logging, tracing, and
statistical models to enable prompt troubleshooting in a distributed
environment, increasing interoperability with enterprise security
infrastructure, and report generation. Develop robust mechanisms to
ensure that products from different companies that work well
separately on an Eclipse package work well together (e.g., 113806,
- Increase enterprise developer productivity
- Team Workspace: When joining a team, allow users to share their
current preferences, workspaces, and plug-ins and make sure that all
user configuration settings are stored in a preference file. Allow
user preferences and pre-populated workspaces to be shared amongst a
- Seamless support for a broad variety of roles
- Improve development time integration across development roles
- Provide support for development time work flow. (e.g., an
extensible process flow that could enforce a series of activities for
a code branch commit, code review, statistics, unit test).
- This would include support for more roles and tools (e.g. extend
our current Java only development model to cover defects, test cases,
- Security: Improve configurability (e.g. of capabilities) to allow
for the definition of unique roles such as admin, developer. This
configuration, then, can be used to control read, write, and other
permissions based on roles.
- Support for digital signing of plug-ins will enable that these
plug-ins can be executed only by specified roles.
- Improve integration between Eclipse’s build system and external
build systems and deployment tools
- Provide a batch mode mechanism that makes it easier for 'headless'
Eclipse tools to execute. For example, a batch mode for building and
creating Eclipse itself.
- Integration with license management. This ensures that a framework
exists such that license needs of various commercial applications
integrating with Eclipse can ensure compliance with their specific
license needs. The license needs could include a maximum number of
concurrent users, duration of usage, etc.
- Manageability:JMX is rapidly becoming a standard for Java
developers who want to incorporate manageability into their
applications during development time. The new J2SE 1.5 JDK includes JMX
support. Support for JMX design patterns which enable developers to
model manageability and drive transformation to JMX MBeans and other
management technologies. Additionally, Eclipse support for JMX
creation, via wizards, code assist or other tooling, and monitoring
would help in automating the management instrumentation process.
Design for Extensibility: Be a Better Platform
Within the Eclipse community, many development projects are defining
new development platforms on top of other Eclipse projects. Concrete
examples include the Business Intelligence Reporting Tools, the Data
Tools, and the Device Software Development Platform projects. It is
recognized, however, that some function is not strictly required by the
underlying projects but are important to enable other platforms to
succeed. This theme also includes effort to assure platform integrity.
- Solid Integration across multiple products supported from
- Assuring API compatibility release-to-release, including
- Robust API documentation
- API tools to detect use of internal interfaces
- Assuring release-to-release migration (e.g., resources,
- Provide a better experience for the co-existence of offerings from
multiple vendors in a single Eclipse installation
- Permit offering identity to show through (e.g. On the splash
- Allow for license management of "products" (i.e. Aggregations of
- Allow for updating and uninstalling of products
- Integrated diagnostic capabilities - e.g. When a user encounters
a problem, providing assistance on the where the problem originated,
- Provide an RCP-based installation utility that can install
Eclipse plus other non-Eclipse artifacts. This needs to be integrated
with Update Manager
- Expose meaningful building block APIs
- Open the internal JDT (UI) interfaces to enable tools to
seamlessly facilitate and interact with the JDT core and UI layers.
For example the parsing and AST functionality.
- Enhance the Debug API to enable seamless debugging across mixed (Java+native) languanges
- Provide a more flexible mechanism that can be used to debug
non-Java programs. This is both in the debug model and presentation
- Provide for debugging a system comprised of multiple languages
- Loosen the strong file orientation by providing an abstraction
layer of logical objects to allow one to extend Eclipse functionality
tools working at a higher abstraction level. For example,
- Marker and Quick fix capabilities. In this connection a less
restrictive structuring of projects would be desirable (some tools
would like to structure and group projects in a more hierarchical
- Contributing actions on models that do not have a one-to-one
mapping to files on the user’s hard disk. This would, for example,
allow a team provider’s repository operations to be made available on
- Existing views like the navigator and problems view should be
generalized to handle logical artifacts and, in general, there should
be better control over what is displayed in views and editors based
on the logical models that the end user is working on.
- Enable task automation
- Provide access to Eclipse APIs and resources from scripting
- Provide the capability to record, edit, playback macros,
representing a set of user interface actions.
This theme describes additions to Eclipse to provide standardization and extensibility to enable embedded tools providers, real-time operating system providers, semiconductor vendors, and hardware developers to create embedded-specific capabilities on top of standard Eclipse projects such as the Platform, JDT, eRCP, CDT, and TPTP. These capabilities should include:
- Hardware and Target OS bring-up capabilities
- Target OS independent debugging and profiling with extensible OS visibility
- Remote target launching, exploring, and management
- Configuring, building, deploying, and managing target images using multiple tool chains
- Embedded GUI design
- Target simulation and emulation capabilities
- Embedded testing capabilities - monitoring, profiling, and unit testing
Rich Client Platform
The Eclipse RCP is a Java-based application framework for the desktop. Building on the Eclipse runtime
and the modular plug-in story, it is possible to build applications ranging from command line tools to
feature-rich applications that take full advantage of SWT’s native platform integration and the many
other reusable components.
In 2006, the key priorities for this theme are:
- Each project is requested to ensure they provide support for building RCP applications through frameworks,
documentation and tutorials. It is important that that the projects assume they are not running in the context
of an IDE. Ex. deploy within an OSGI bundle.
- To improve authentication and security (user authentication and credentials, role based security, and
role-based plug-in loading)
- Framework for disconnected use; ex. how to disconnect and how to synchronize when reconnected.
- Make it easy to build standalone products on RCP from Eclipse plug-ins that also run in an IDE.
- Core framework installer for RCP and install metadata store (like JRE or .NET framework)
- Rapid application development (RAD) tooling for Eclipse RCP.
Simple to Use
The Eclipse components need to not only provide features that advanced users demand, but also be something
that users find simple to use. The goal of this theme is to ensure that Eclipse-based products are simple to
use for users with widely-varying backgrounds and skill sets performing a variety of tasks. Examples include:
- Provide Eclipse User Experience Guidelines to ensure consistency and usability (including Accessibility)
across projects. [see 121303].
- Usability reviews and updates to new and existing user interfaces to streamline common processes and
clarify concepts and terminology.
- Improving support for Cheat Sheets to assist users in performing tasks. [e.g. 56234, 69735]
- User personas/roles to streamline the user interface to adapt to specific user needs. [e.g. 73941]
- Enhanced user documentation, tutorials, white papers, demonstrations.
For example, if a user interface wizard provides a short path to performing a task, make sure that
usability studies have identified the most common task performed by the target users.
Enable Consistent Multi-language Support
The original vision of Eclipse was to accelerate the creation of IDEs. There is a lot of work to do to
make it simpler to create language-specific IDEs. Our vision is to:
- Create an environment where a limited number of well-defined extension points for compilers, parsers,
debuggers, building, launching, etc. will simplify the process of creating Eclipse-based offerings. This
enables add-in providers to easily plug in tools that support multiple languages while enabling the IDE
developers to abstract away the language independent components (Abstract Development Toolkit)
- Enable IDE users to simultaneously and seamlessly use multiple languages in the development of a project.
(IDE User Support for Multiple Languages)
Plug-in providers have a strong need for an abstract development toolkit where a variety of plug-ins (e.g.,
editor, managed build system, debugger) can be plugged in for all development environments including Java. This
is more efficient than integrating each plug-in with each separate development environment. Focus on abstract
development toolkit improves componentization and consistency across development environments, makes each
component within the development environment more robust, and adds flexibility to increase the reach of Eclipse
to a variety of development environments (e.g., Fortran, COBOL) quicker. This opens up 1:1 relationship between
add-in component and development environment into a richer m:n relationship.
The support for Abstract Development Toolkit includes the following features:
- Make it easier to create language specific tools in a consistent way: consistent generic components / APIs
to add languages.
- Generic APIs - not Java-specific
- Ability to create tools for other languages
- Language toolkit model which provides public APIs sufficient for tools builders.
IDE User Support for Multiple Languages includes
- Enabling source files written in multiple languages within the same project. For example, a substantial fraction of projects have source files in (1) C/C++ and Fortran and (2) C/C++ and Java for code reuse or interoperability purposes.
- Enable language-sensitive context based on the specific language source file in focus. This includes both showing the relevant concepts for a specific language and hiding ones that are not relevant for the language.
Appealing to the Broader Community
While Eclipse has been very successful with Java developers on Windows systems, we would like to see Eclipse used and embraced in more diverse developer communities:
- Additional operating environments:
- Continue the kinds of improvements seen by adding J2SE5 support to the JDT, where a new and growing developer community was welcomed.
- Continue the work to provide basic tools and frameworks for supporting the construction, deployment and management of web service applications. Example tools include: UDDI browser, XSL/T editor, and WSDL tools.
- Improve SWT consistency across operating systems [#106188]: plug-in providers noted differences in the behavior of Eclipse on Windows and Linux. Window systems sometimes differ in things like the exact sequence of events reported for a given action. This kind of inconsistency can result in platform specific code and increased testing requirements. More consistent behavior would ease the burden on plug-in providers. Over 80% of Eclipse downloads are for Windows, followed by ~20% for Linux, and a very small fraction are for operating systems such as the Macintosh, AIX, Solaris, and HP-UX.
- A broader range of supported platforms [#51628, #78839]: the Eclipse platform supports x86-64, ia64 on Linux already, as well as Mac OS X, but do all projects?
- Building bridges into other open source communities: examples would be LSB-compliant packaging [#108610], and cooperating closely with the Apache Harmony project in qualifying a fully open source JVM [#108614].
- Progress in supporting Vista (e.g., file system, SWT, ...)
- Vertical market-specific frameworks (e.g., the health care initiative)
- Using an open and transparent process, create, maintain and deliver language packs translated into multiple languages in a timely manner. The languages to consider are: English, Simplified Chinese, Traditional Chinese, Japanese, French, German, Spanish.
- Every project should make a statement on their accessibility compliance. In the U.S., this means Section 508 compliance; in the European Union, this is the Web Accessibility Initiative of the World Wide Web Consortium (W3C).
back to top
Rich Main and
|Add-In Provider Board Representatives
||Web Tools PMC
back to top
Anurag Gupta (Intel) wrote the first draft of the themes and provided much feedback and leadership in v2.0.
back to top