Themes and Priorities

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)

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.

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.

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:

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.

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:

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.

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

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