The Eclipse Project DRAFT 3.3 Plan

    Please send comments about this draft plan to the eclipse-dev@eclipse.org developer mailing list.

This document lays out the feature and API set for the next feature release of the Eclipse SDK after 3.2, designated release 3.3.

• Release deliverables
• Release milestones
• Target operating environments
• Compatibility with previous releases
• Themes and Priorities
• Work Areas

Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, we (the Eclipse Project PMC) post plans in an embryonic form and revise them throughout the release cycle.

The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change.

The remainder of the plan consists of plan items for all of the sub-projects under the top level Eclipse Project. Each plan item covers a feature or API that is to be added to the Eclipse Project deliverables, or some aspect of the Eclipse Project that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single component; others may involve coordinated changes to several components; other may pervade the entire SDK. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order.

With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.

The current status of each plan item is noted:

• Committed plan item - A committed plan item is one that we have decided to address for the release.
• Proposed plan item - A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it. After due consideration, a proposal will either be committed or deferred.
• Deferred plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point.

Release deliverables

The release deliverables have the same form as previous releases, namely:

• Source code release for all Eclipse Project deliverables, available as versions tagged "R3_3" in the Eclipse Project CVS repository.
• Eclipse SDK (runtime binary and SDK for Equinox, Platform, JDT, and PDE) (downloadable).
• Eclipse Platform (runtime binary and SDK for the Equinox and Platform only) (downloadable).
• Eclipse RCP (runtime binary and SDK for the Rich Client Platform) (downloadable).
• Eclipse JDT (runtime binary and SDK for the Java Development Tools) (downloadable).
• Eclipse PDE (runtime binary and SDK for the Plug-in Development Environment) (downloadable).
• Eclipse SDK Examples (downloadable).
• SWT distribution (downloadable).
• Equinox OSGi R4 framework and assorted service implementations (downloadable).

Release milestones

Release milestones, occurring at roughly 6 week intervals, exist to facilitate coarse-grained planning and staging. The milestones are:

• Thursday Aug. 10, 2006 - Milestone 1 (3.3 M1) - stable build
• Friday Sep. 22, 2006 - Milestone 2 (3.3 M2) - stable build
• Friday Nov. 3, 2006 - Milestone 3 (3.3 M3) - stable build
• Friday Dec. 15, 2006 - Milestone 4 (3.3 M4) - stable build
• Friday Feb. 9, 2007 - Milestone 5 (3.3 M5) - stable build
• Friday Mar. 23, 2007 - Milestone 6 (3.3 M6) - stable build - API complete - API Freeze
• Friday May 4, 2007 - Milestone 7 (3.3 M7) - stable build - feature complete - development freeze - lock down and testing begins

Our target is to complete 3.3 in late June 2007. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.

Target Operating Environments

In order to remain current, each Eclipse release targets reasonably current operating environments.

Most of the Eclipse SDK is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions of the Eclipse SDK (including the RCP base, SWT, OSGi and JDT core plug-ins) are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4, etc.).

In general, the 3.3 release of the Eclipse Project is developed on a mix of Java 1.4 and Java5 VMs. As such, the Eclipse Project SDK as a whole is targeted at both 1.4 and Java5 VMs, with full functionality available for 1.4 level development everywhere, and new Java5 specific capabilities available when running on a Java5 VM. Similarly, in cases where support has been added for Java6 specific features (e.g. JSR-199, JSR-269, etc.) Java6 VMs are required.

Appendix 1 contains a table that indicates the class library level required for each plug-in.

There are many different implementations of the Java Platform running atop a variety of operating systems. We focus Eclipse SDK testing on a handful of popular combinations of operating system and Java Platform; these are our reference platforms. Eclipse undoubtedly runs fine in many operating environments beyond the reference platforms we test, including those using Java6 VMs. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Eclipse on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse on a reference platform.

The Eclipse SDK 3.3 is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):
( new table format + multiple content changes)

Caveat: Using IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4 on Vista

Although we expect this to be fixed in IBM Java5 SR5, there is currently a conflict between the use of DirectDraw by the AWT libraries in IBM Java5 SR4 and the Windows Vista "Aero" theme. Although the Eclipse SDK itself does not use these libraries (and thus runs well on Windows Vista using that VM), other plug-ins that make use of the conflicting AWT capabilities may cause the advanced features of Aero to be disabled. As a workaround to avoid this problem, you can add -Dsun.java2d.noddraw=true to the VM arguments when launching Eclipse, which will prevent the AWT libraries from using DirectDraw.

Because Java 1.4.2 and Java5 based platforms are used for most Eclipse development, those platforms are listed here. Although there are teams doing some Java 6 based development we have not included specific Java6 VMs, since they have not yet received the general level of testing we require. We expect that Eclipse will work fine on other current Java VMs running on window systems supported by SWT, but can not flag these as reference platforms without significant community support for testing them.

Similarly, although untested, the Eclipse SDK should work fine on other OSes that support the same window system. For Win32: NT, 2000, and Server 2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.

SWT is also supported on the QNX Neutrino operating system, x86 processor, Photon window system, and IBM J9 VM version 2.0. Eclipse 3.3 on Windows or Linux can be used to cross-develop QNX applications. (Eclipse 3.3 is unavailable on QNX because there is currently no 1.5 J2SE for QNX.)

Internationalization

The Eclipse SDK is designed as the basis for internationalized products. The user interface elements provided by the Eclipse SDK components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles.

Latin-1 locales are supported by the Eclipse SDK on all of the above operating environments; DBCS locales are supported by the Eclipse SDK on the Windows, GTK, and Motif window systems; BIDI locales are supported by the Eclipse SDK only on Windows operating environments.

The Eclipse SDK supports GB 18030 (level 1), the Chinese code page standard, on Windows XP and 2000, and Linux/GTK.

German and Japanese locales are tested.

BIDI support

SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering and displaying BIDI text. Within these limitations, the Eclipse SDK tools are BIDI enabled.

Compatibility with Previous Releases

Compatibility of Release 3.3 with 3.2

Eclipse 3.3 will be compatible with Eclipse 3.2 (and, hence, with 3.1 and 3.0).

API Contract Compatibility: Eclipse SDK 3.3 will be upwards contract-compatible with Eclipse SDK 3.2 except in those areas noted in the Eclipse 3.3 Plug-in Migration Guide . Programs that use affected APIs and extension points will need to be ported to Eclipse SDK 3.3 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 3.3 APIs would ensure compliance with Eclipse SDK 3.2 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: Eclipse SDK 3.3 will be upwards binary-compatible with Eclipse SDK 3.2 except in those areas noted in the Eclipse 3.3 Plug-in Migration Guide . Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.3 will not be usable in Eclipse SDK 3.2. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Eclipse SDK 3.3 will be upwards source-compatible with Eclipse SDK 3.2 except in the areas noted in the Eclipse 3.3 Plug-in Migration Guide . This means that source files written to use Eclipse SDK 3.2 APIs might successfully compile and run against Eclipse SDK 3.3 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Eclipse SDK APIs, they will not be usable with an earlier version of the Eclipse SDK.

Workspace Compatibility: Eclipse SDK 3.3 will be upwards workspace-compatible with Eclipse SDK 3.2 unless noted. This means that workspaces and projects created with Eclipse SDK 3.2, 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.3 and upgraded to a 3.3 workspace. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project (e.g., the .project file), which may propagate between workspaces via file copying or team repositories. Individual plug-ins developed for Eclipse SDK 3.3 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.3 plug-in developers are responsible for ensuring that their plug-ins recognize 3.2, 3.1, 3.0, 2.1, and 2.0 metadata and process it appropriately. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on Eclipse 3.3 will be unusable with a product based an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.3 will generally be unusable with earlier versions of Eclipse.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified in the Eclipse SDK API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Themes and Priorities

The PMC of the Eclipse Project has identified six major areas of work, that will be the priorities for this development cycle. These areas will address the major themes identified by the Eclipse Requirements Council (Themes and Priorities v2.0).

Work Areas

• Components
• Consumability
• Java
• Vista
• UI Evolution
• API

Components

This work will enhance Eclipse's use of, and support for, software components, covering everything from component programming models such as Declarative Services, API tools, incremental building and fine-grained function delivery.

Committed Items (Components)

( committed, wording has changed) Target Provisioning. Currently, users wanting additional function supplied by others must manually acquire and install these additional bundles in their target platform. This process is tiresome and error-prone. As an extension to the proposed provisioning work, we will add the ability to provision targets directly from bundle repositories as well as from other locations on the local machine. [ PDE] (154081)

( committed) Application Model. The OSGi R4 MEG specification includes an application model that significantly decouples the application from the rest of the system. The net result is OSGi (and thus Eclipse) as a more flexible application container, for example allowing multiple applications to run concurrently and improved lifecycle around the application. These characteristics are important both to the manageability of the system (e.g., simplifying and clarifying the shutdown process) but also to various RCP scenarios such as Kiosk-mode and Application Container models. In 3.3 we will implement and adopt the MEG application model. [Equinox] (154084)

( committed) OSGi R4.1 Specification Work. Much of the success Eclipse has enjoyed with OSGi comes from the fact that the Eclipse community has played a very active role in the evolution of various OSGi specifications. With increased interest in OSGi and Java modularity (see JSR 277, JSR 291 and JSR 232) this participation has never been more important. In addition to promoting Eclipse use-cases and the evolution of these standards to benefit Eclipse, there are a number of gaps in the OSGi specifications that Eclipse is currently filling in specific ways and should be addressed in R4.1. For example the management of API in metadata (x-friends and x-internal), integration techniques for third party and legacy code, in-place execution of bundles, basic notions of data location, etc. The Equinox team will continue their active participation in these specification processes and keep Eclipse on the leading edge of Java componentization. ( Note that originally this plan item referenced "OSGi R5" but the next version of the spec is going to be called "R4.1" so we have updated the item accordingly.) [Equinox] (154085)

( committed) Server side support. First it was tools, then it was applications, now server-side programmers are waking up to the power of componentization delivered by Eclipse and OSGi. In the 3.2 cycle an Equinox incubator was started to investigate the use of Eclipse on the server. It started as a very modest servlet bridge allowing Eclipse to run inside a servlet engine and handle servlet requests and has been evolving into a full-blown appreciation of what it means to componentize server software. There are many possible directions here and there is no way the Equinox team proper will be able to track, support and participate in all. However we will spend time understanding the basic requirements as they apply to the base framework and add-on services and look to support the use-cases presented by various other Eclipse projects that are adopting Eclipse on the server (e.g., ECF, ECP, Corona). [Equinox] (154087)

( committed) Help content generated on-the-fly Currently it is not possible to write all your help content in your own format, and have it converted into HTML, TOC, keyword index, and context help on-the-fly. For the table of contents you must supply the information in the toc XML format, you cannot use any other format or write code to contribute tocs. The same restriction exists with keyword index content. This item consists of adding API for toc and keyword index providers, and ensuring that a full end-to-end generated doc set is possible. We will use DITA as a showcase XML content format. [UA] (175016)

( committed) Improve componentization of user assistance content More flexibility for filtering, such as OR and IF/ELSE clauses in filter condition, and ability to plug-in any type of filter. Adopt help's extension features and content replace for all other forms of user assistance (e.g. welcome, cheat sheets). Support for properties files for separating words from content structure in all of UA. Also provide a better mechanism to control how UA content is arranged and ordered (for example, the order of books in the table of contents). [UA] (175018)

Proposed Items (Components)

Improved support for provisioning. Eclipse has advanced quite quickly with new use-cases (RCP, Equinox, server side, etc.) and new technologies (e.g., OSGi and OSGi's MEG) coming into the picture. To date Update Manager has not been enhanced to support or exploit these changes. In 3.3 we will investigate provisioning support for enhanced workflows, the ability to update the so-called "root files" (e.g., startup.jar, eclipse.exe), improved efficiency (download and disk footprint), support for right-grained discovery and acquisition of function as well as integration with differing repository types. This effort also includes enhancements to the tooling around provisioning. [Update] (154077)

Bundle Management. Managing even modest systems of bundles can be complex and error prone. There are several places in PDE where developers need to list or select sets of bundles (e.g., launch configurations, target setup, etc). In many cases the environment already includes relevant grouping constructs (e.g., features, working sets, bundle groups). PDE should surface these to developers in a clear, consistent and pervasive fashion. [PDE] (154082)

Deferred Items (Components)

( deferred) API tools. More components means more API and an elevated need for solid APIs, evolved but compatible APIs and the correct and understood use of APIs. This cannot be achieved without supporting tooling. Today PDE includes sophisticated support for classpath management and access rule management based on information in the manifest of bundles to facilitate the capture of package and class references. In 3.3. we will expand this to cover finer-grained API contracts (e.g., clients should not call foo() or extend Bar). Similarly, developers will be given effective mechanisms for discovering, visualizing and minimizing dependencies in their code, bundles produced by third parties and non-bundled code libraries. Tooling in support of checking and managing the evolution of component and package version numbers will also be supplied. [PDE] (154078)

( deferred) Bundle/Module Development Tools. In 3.1 and 3.2 PDE made gigantic strides in support for traditional OSGi bundle development. Even still, in 3.3. we will improve various workflows and classpath management strategies to promote the development of robust and independent right-grained components. This covers everything from increased quick-fix and manifest editing support to deeper integration with JDT (e.g., support for searching JARs that are not in the workspace without implicitly importing the JARs). In addition, as JSR 291 evolves in the Java SE 6 time frame, PDE will be there to provide developer support. 3.3 will include tooling around OSGi Declarative Services and the new application model as well as improved support for launching other frameworks, Java applications with bundle based classpaths and "hot launching" frameworks. ( Note: significant work was done on this item, but not enough to cover it's full scope. See the bug for more info.) [PDE] (154079)

( deferred) Incremental Plug-in Build. With the increase in plug-ins coming from and going to third parties the development cycle needs to be more incremental. In the Eclipse project itself we have started to consume pre-built plugins such as ICU4J and SSH2. This trend is likely to continue as, for example, Apache seeks to deliver their libraries as bundles and more people look to consume individual bundles/components from Equinox and similar projects. As such, the build process should support the incremental building of plug-ins (that is building plugins individually) based on a set of pre-built plugins kept in some sort of provisioning repository. Plug-ins coming out of the build should feed into said repository to be used as a base for future builds. This ability will in turn enable the more frequent building of whole systems (since you build only what has changed) and simplify incremental, milestone and release build cycles. [PDE Build] (154083)

(End of items for Components.)

Consumability

This work will make it easier for users to get Eclipse, install it on their systems, and configure it for their use. It will also enhance the error handling and reporting mechanisms to make it easier to service Eclipse in the field. Finally, it will improve the scalability and performance of Eclipse, to provide a better experience for users working with many plug-ins and large data sets.

Committed Items (Consumability)

( committed) Remote help Packaging a comprehensive set of help content with a product can significantly increase its size. Instead of bundling it with the product, allow help content to be served from a remote infocenter. This includes all forms of help content: documents, table of contents, keyword index, and context help. Local content is also allowed alongside the remote content, and it should behave and appear to the user as though it were installed locally. [UA, Releng] (175006)

( committed, follow on work in next release) Improve the launching experience. We will look for ways to improve the current launching experience. This may include efforts such as using SWT to build the splash screen, improving the look and utility of the workspace launcher, supporting "fast switching" between workspaces, and simplifying the experience for first-time users. [SWT, Runtime, Workspace, UI, UA] (154088)

( committed) Improve serviceability. When an end user encounters a problem with Eclipse, it is important for support teams to be able to diagnose the root cause of the failure, and identify the failing plug-in. Eclipse should have enhanced error reporting tools that make it easy for end users to report problems. Tools should be available at all times, so that knowledgeable users can diagnose unexpected behavior such as slow-downs or exceptional memory use. Error handling is done in a variety of ways within the platform which are not extensible to RCP applications. An improved story would allow for the inclusion of application defined error support (such as a link to a support centre for the product) and remote monitoring/inspection of system health and would tie the current error reporting story together into a solution with a more consistent look and fewer error reporting paths for developers. [Runtime, UI] (154090)

( committed) Managing and sharing settings. Currently settings are either scoped at the workbench/workspace level or the project level. However, there are cases where associating settings with other scopes, such as a working set or perspective, would be beneficial. Similarly, a product should be able to specify the default settings for a particular perspective. We will also look for ways to simplify how we share settings and other interesting state, such as breakpoints, bookmarks, perspectives, key bindings, etc. [Runtime, Workspace, UI] (154097)

( committed) Platform level proxy settings. There are at least three proxy settings pages in Callisto. We will work with the Eclipse community to make sure that the core capabilities from these pages are made available at the Platform level, as a single settings page that can be consumed by all. [Runtime, Team, Update, UI] (154100)

( committed) GTK Printing. We will provide printing support on GTK. [SWT] (154101)

( committed) Search based navigation. Because traditional navigation-by-browsing does not scale to large data sets, we should generalize and extend the existing search-based rapid navigation mechanisms (e.g. "Quick Find Class"). [UI, UA] (154104)

Proposed Items (Consumability)

Ship Finer-grained Components. The Eclipse project produces three major outputs, the Platform, JDT and PDE. These are exposed as zips on download sites and features on update sites. Those wanting to get just part of one of these components (e.g., Help, Update, JDT Core) must first discover which zip or feature contains the desired function, acquire that container and finally identify and extract the desired plug-ins. To make this easier we will revise the grouping structure to capture more independent and re-usable components. [All components] (154102)

Performance focus. We must continue to improve overall performance and memory consumption, with a particular focus on working with large numbers of plug-ins and large amounts of data. [All components] (154106)

( new) Help keyword index In 3.2, keyword index support was added to the Help system. However, as yet the Eclipse SDK does not have keyword index content. This item consists of contributing a comprehensive and complete keyword index for Eclipse as well as the necessary tooling to create it (e.g. ant task to extract meta keywords from html, etc). This also includes UI enhancements for the overall presentation of the keyword index and any necessary usability enhancements. [UA, Doc] (175008)

Deferred Items (Consumability)

( deferred) Customization. Eclipse lacks customization capabilities aimed at end users and product packagers. More generally, component development and use is fraught with producer/consumer problems. Component producers implement solutions that address a number of use-cases and scenarios but inevitably consumers come up with additional, sometimes quite divergent requirements. We will investigate mechanisms and facilities that allow component consumers to "override" or replace metadata specifications in the components they are consuming. Such mechanisms would, for example, allow consumers to configure menus, tool bars, and perspectives of their Eclipse installation as well as refine plug-in dependency declarations. [Runtime, UI] (154099)

(End of items for Consumability.)

Java

The Eclipse Java Development Tools are the premier Java development environment in the industry today. We must address the new capabilities of Java SE 6 and continue to refine and extend the features JDT provides to maintain its leadership position.

Committed Items (Java)

( committed, wording has changed) Enhance launching support. We should simplify the launch experience for novice users with single click, context sensitive launching, and with launch configurations managed via resource properties. For advanced scenarios, we should allow plug-ins to contribute additional pages to launch configurations so that plug-in specific information (such as profiling and code coverage settings) can be associated with each configuration. Additionally we should support mixed mode launching, and allow more than one plug-in to contribute launchers for the same configuration type and mode (allowing the user to select a preferred launcher). [Debug] (154107)

( committed) Extend Clean Up. Add formatting, organize import and sort members to 'Clean up', offer clean up profiles, and invoke clean up on user defined events. [JDT UI] (154109)

( committed) Compiler API (JSR 199). In order to conform to the forthcoming tool API for compilers (JSR 199), the Eclipse compiler should provide a front-end implementing the tool API included in Java SE 6. [JDT Core] (154111)

( committed, wording has changed) Support for Java SE 6 debug features. Implement new Java SE 6 features in the Eclipse Java Debug Interface (JDI) client including support for heap walking (retrieve instance counts, all intances of specific types, and all references to an object), forcing an early return from a method with a specific return value, and improved class prepare event filtering. [JDT Debug] (154115)

Proposed Items (Java)

More refactorings. We will finish the 'Fix Deprecation' refactoring that didn't make it into 3.2, and add the new refactoring 'Replace Invocation'. More refactoring API will be offered in the plug-in org.eclipse.jdt.core.manipulation so the refactoring infrastructure can be used with a UI. [JDT UI] (154108)

Enhance Annotation Processing Tooling. An APT command-line tool should be provided as a complement to the batch compiler and/or Ant javac adapter, in addition to the Java IDE support within release 3.2. APT should also support the new standard Annotation Processing API (JSR 269) introduced in Java SE 6, as opposed to the provisional API from Sun introduced in Java SE 5 that is currently implemented. Also, the APT integration in IDE should be improved in various areas, including editor reconciling and code assist. The editor reconciling experience should work correctly even if the Java builder is not active. Currently, if a processor generates types, those types are ignored during reconcile. Instead, they should be modeled using working copies, and provide the same level of functionality as JDT when autobuild is turned off. Also, on the code-assist front, we should provide a simple API for processors to supply domain specific knowledge to completions inside annotation values. [JDT APT] (154110)

Add more class file targets for compiler. The compiler should support more configurable class file targets, including CLDC 1.0, CLDC 1.1 and possibly JSR 14 (generics experimentation for 1.4 VMs). [JDT Core] (154113)

Deferred Items (Java)

None at this time.

(End of items for Java.)

Vista

Microsoft Vista is a significant new desktop platform that we expect will become available during this development cycle. We should fully support running the current, win32-based version of Eclipse on Vista. We should also port SWT to WinFX and the Windows Presentation Framework.

Committed Items (Vista)

( committed) Fully support the win32 version of SWT on Vista. We should ensure that applications built on the win32 version of SWT work as well as any other win32 API based application on Vista. This will increase our testing and support effort and potentially require new development to work around platform specific differences. [SWT] (154116)

( committed "early access" version) Port SWT to WinFX and WPF. We should port SWT to WinFX and the Windows Presentation Framework. Since 64-bit systems are becoming increasingly prevalent on the desktop, we should ensure that this port is both 64-bit and 32-bit capable. ( Note: In the 3.3 timeframe, we are committed to producing a WPF port that will be suitable for early access style investigation on the platform. Significant follow on performance and feature completeness work (such as 64-bit support) will occur in our next release.) [SWT] (154117)

Proposed Items (Vista)

None at this time.

Deferred Items (Vista)

( deferred) Generalize the win32 version of SWT to win64. We should merge the work being done by the Eclipse community to implement a win64 implementation of SWT into the main win32 code base. This will require extensive review of the new code and a significant effort to merge and test the pervasive changes. [SWT] (154118)

(End of items for Vista.)

UI Evolution

The goal of this work is to provide a better basis for building modern, rich user-interfaces, by addressing areas where more flexibility and more consistency are needed. We will use these capabilities to refine the user-interface of the Eclipse IDE. In addition, we will implement of the most requested missing IDE productivity features.

Committed Items (UI Evolution)

( committed) Investigate background saving of editors. Modern applications allow editing sessions to be saved in the background, allowing the user to continue editing or close the editor without waiting. We should investigate whether this style of interaction can be built on top of the Eclipse editor framework. [Platform Text, JDT Text, Platform UI] (154122)

( committed) Improve workbench usability. We should review how users interact with the workbench, such as how editors, views, and other screen real-estate are managed (e.g. fix the broken minimize), and find ways to make this a better experience for them. This includes improving the new trim support by allowing the end user to hide/show, close and otherwise configure trim items, improving navigation from hovers (e.g. quick diff), making fast views more flexible (fast views on all sides, fast view orientation affinity, fast view bars show text option). [Platform UI, Platform Text, JDT UI, JDT Text] (154120)

( committed) JFace Enhancements. Ensure that the reusable components in JFace fully support the SWT widget set, such as support for the new custom draw capabilities of the Table and Tree widgets. Also, implement some of the components that we do not use in the SDK currently that the community is requesting. Some examples include: spinners, secure editors (such as password entry fields) fields that enforce a format (such as fields for currency and percentages), etc. [Platform UI, SWT] (154123)

( committed) Mozilla Everywhere. For situations where the existing, platform-browser-based Browser control is not sufficient, we should support embedding of Mozilla on all platforms. This would allow developers to implement code that worked against a common back end, so that they could access a common DOM, or surface the browser's HTML editing support. [SWT] (154124)

( new, committed) UI Forms face-lift UI Forms will be refreshed visually and functionally. Color management will be revised to increase consistency of color across all the platforms Eclipse runs on. Enhancements will be made to both the header area and field decoration support. Eclipse SDK clients of UI Forms will take advantage of the new capabilities. [UA, PDE] (175158)

Proposed Items (UI Evolution)

Implement missing text editor productivity features. We should provide some of the long awaited productivity features that the community has voted for. Examples include double-click-drag to select multiple words, triple-click, extensible hyperlink support and spell checking. [Platform Text, Platform UI, SWT] (154119)

Improve multi-instance view management. Views such as Search and Synchronize use a drop-down menu to manage multiple pages. Another possibility would be to use multiple view instances. However, the presentation and management of these two approaches are different. Multiple view instances should support different view presentations. That is, the user (or product) should be able to decide whether multiple views use tabs or a drop-down menu. There are also shortcomings in multi-view management (e.g., views are managed at the perspective level but some tooling may require the ability to close a particular view in all perspectives). [UI] (154121)

( new) Help webapp refresh The Help web application's appearance does not currently match the workbench appearance well. However it is common for users to move back and forth between these two windows, resulting in an inconsistent experience for the user. We will refresh several aspects of the Help user experience, including presentation, accessibility issues, optional footer for legal information, automatic bread crumbs. [UA] (175023)

( new) Ubiquitous cheat sheets Cheat sheets will be commoditized by lowering the price of authoring and publishing. We will make it easy to whip up a cheat sheet quickly, hook appropriate commands for 'Do it for me' links, exchange cheat sheets as attachments or as URLs to remote cheat sheets. Finally, we will explore making a web-based cheat sheet renderer to expand their use beyond the workbench cheat sheet view. [UA, PDE, Doc] (175024)

Deferred Items (UI Evolution)

None at this time.

(End of items for UI Evolution.)

API

This work area deals specifically with issues concerning the application programming interfaces provided by the Eclipse Project. We will identify API whose function has been superceded, and ensure that the SDK does not depend on this API. We will encourage adoption within the SDK of some of the more recent additions to Eclipse, such as the command framework, Equinox preferences, tabbed properties and the common navigator. We will work with the community to ensure that needed functionality is made available as API, when it reaches appropriate levels of maturity.

Committed Items (API)

( committed) Generalize editor annotation and ruler support. We should allow plug-ins to contribute additional vertical rulers to show additional information (e.g. code coverage). We should support live annotate "color by age" in addition to "color by contributor". [Platform Text] (154125)

( committed) Adopt the new UI features. We should adopt the following items across the entire SDK UI: the new command framework, preference initializers, field assist, SWT column sort indicators, working sets, tabbed properties view and the common navigator. [UI, JDT UI, PDE, Team, Text] (154127)

( committed) Provide access to more native controls. We should provide access to more of the native controls that are available on each platform, such as date and time pickers, and table header widgets. In addition, we should enable more features of existing native controls, such as table wrapping on Windows. [SWT, UI] (154128)

( committed) Custom widget API support. Investigate ways to simplify the process of writing custom widgets, including making available, as API, some of the currently internal capabilities of the custom widgets implemented in the SDK, such as drag under feedback for drag & drop. [SWT] (154129)

( committed) Finish re-work of commands and key bindings. In 3.2, we built some important infrastructure that will allows us to rationalize our commands and key bindings story. We need to complete this effort, making sure the new story supports all of the existing functionality (e.g action sets), and migrate over to the new support. We also need to make it easier to add and edit key bindings. [UI] (154130)

( committed) JFace data binding. In 3.2, we developed a data binding framework for JFace but did not make it generally available. We should continue to work towards providing a public API for this framework and investigate how it will be delivered and used within the SDK. [UI] (154132)

( committed) Improve compare. The Compare plugin has not undergone much work in the last few releases and is showing it. From an architectural standpoint, there are several Compare internals that need to be made API in order to properly support clients and there are also several polish items that have been identified by Eclipse development teams. In addition, new ISaveable support was added in 3.2 and we should investigate integrating this into Compare. From a usability standpoint, the compare editor uses a custom viewer for content which appears similar to the related editor but has a reduced capability which is often confusing for users. Smaller usability issues involve breaking out the outline from the editor into the Outline view. There is supported by compare but is not used by Team or other Platform clients. [Team] (154133)

( committed) Graphics Improvements. The SWT graphics layer should provide support for fractional line widths, dashes and fonts, the ability to flatten paths, image loading/saving improvements, and other similar enhancements. [SWT] (154134)

( committed, wording has changed) APIs for custom debugger integration. Publish public APIs based on the provisional APIs introduced in 3.2 to support custom debugger integration. Features include a debug context service supporting retargettable actions and debug command handlers (for operations such as step and terminate), custom detail panes in the variables view, flexible view wiring and pluggable source lookup. [Platform Debug] (154135)

Proposed Items (API)

Adopt the Eclipse File System. We should ensure that use of the Eclipse File System is pervasive in the platform, and remove any barriers that prevent it from being more widely adopted by the community. For example, we should provide IFileStoreEditorInput and a matching default implementation. [Workspace, UI, Platform Text] (154126)

Deferred Items (API)

None at this time.

(End of items for API.)

Appendix 1: Execution Environment by Plug-in

In the table below, the "3.3 EE" ("3.3 Execution Environment") column indicates the minimum Java class library requirements of each plug-in for the 3.3 release, where the value is one of: