Skip to main content

Eclipse Themes and Priorities

Introduction

This document captures the inputs to the Eclipse Requirements Council as of this date. The inputs are from three major sources:

  1. Strategic Members of the Eclipse Foundation,
  2. the Project Management Committees (PMCs), and
  3. the general membership through the input collected from various Eclipse members.

The themes were generated by collecting requirements from the above sources and then synthesizing themes from the various inputs.

back to top

Fundamental Principles


These are our fundamental principles, which span all of the themes outlined below.

  • 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.

Scaling Up

This refers to the need for Eclipse to deal with development and deployment on a larger and more complex scale. Increasing complexities arise from:

  • 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 over time
  • the dynamic nature of new source code bases and their interaction with configuration management, and
  • build environments involving many different tool chains and build rules.

This requires:

  • 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 performance.
  • 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 overlapping environments
  • 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.

Enterprise Ready

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 centrally
    • 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 paradigm.
    • 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, 111687).
  • 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 team.
    • 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, requirements)
  • 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.
  • Integration
    • 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 release-to-release
    • 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, workspaces)
    • 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 screen)
      • Allow for license management of "products" (i.e. Aggregations of features)
      • 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, which product
      • 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 way).
      • 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 logical artifacts.
      • 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 languages
    • Provide the capability to record, edit, playback macros, representing a set of user interface actions.

Embedded Development

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

Contributors

Name Member
Paul Clenahan Actuate
John Kellerman IBM Corporation
Anurag Gupta Intel
Par Emanuelsson Ericsson AB
Martin Klaus Wind River
Philip Ma Hewlett-Packard Company
Howard Lewis,
Rich Main and
Todd Williams		 Add-In Provider Board Representatives
David Williams Web Tools PMC

back to top

Acknowledgements

Anurag Gupta (Intel) wrote the first draft of the themes and provided much feedback and leadership in v2.0.

back to top



Thank you!

Our thanks to HP, IBM, Intel, Magma and Novell for generous donations to our website infrastructure.

Related Links

Back to the top