Please send comments about this draft plan to the firstname.lastname@example.org developer mailing list.
This document lays out the plan for the next major release of the Eclipse Project, designated release 2.0. The main emphasis of the Eclipse Project 2.0 release will be on improving quality (bug fixing) and performance, with a lesser emphasis on adding new features and APIs.
This plan serves at least two purposes. First, it serves as the blueprint guiding the efforts of the developers working on the Eclipse Project subprojects. The work items committed in this plan were selected over all others because they were judged to provide the most value to customers for this follow-on to the Eclipse Project 1.0 release. Second, this plan serves as an important input to the planning processes of the various customers of the Eclipse Platform. This plan tells them what to expect (or what not to expect) in the next release so that they can plan their projects accordingly.
Plans are rarely completely unchanging over the life cycle of a release, and this project is no exception. We will update this document as required to reflect any changes to the 2.0 release plan. While we certainly do not expect to backtrack on items already committed, we do anticipate adding further committed items to the list. This plan already includes a number of extra work items which we are presently unable to commit to for the 2.0 release due to time, but which are nonetheless worthy of being solved. Where possible, we will try to complete these items, and will revise this plan as soon as we know we can make a definite commitment. The individual Eclipse Project subproject and component web pages and developer mailing list archives contain further, in-depth information about how a component is changing. Particular problem reports being worked on for the 2.0 release can be tracked through the bug database; the "Target Milestone" field reflects when a work item will become available in the main development stream.
[This draft plan has changed significantly over the previous draft dated December 21, 2001. The Eclipse SDK user community has told us that they want to see additional improvements in certain areas, and that an early release that did not address their needs would be less interesting, and would only delay the availability of the follow-on release that did address their concerns. We therefore extended the development schedule to include a number of new committed items, many of which were previously known but on the uncommitted list. In addition, we deleted a few uncommitted items that we know will not be done in the Eclipse Project 2.0 release, and revised several items to more accurately describe what we will be doing. We added 3 more milestones (M4, M5, M6), and are now targeting May 2002 for the Eclipse Project 2.0 release, rather than April.]
The release deliverables are:
The release milestones are:
The 2.0 release is targeted for May 2002 [formerly April]. 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.
Most of the Eclipse SDK is "pure" Java and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java 2 Platform itself. The 2.0 release of the Eclipse Project will be written against version 1.3 of the Java 2 Platform APIs, and targeted to run on either version 1.3 or 1.4 of the Java 2 Runtime Environment, Standard Edition.
We plan to test and validate the Eclipse SDK 2.0 on the most up-to-date Java 2 Platform implementations available. These are:
|Operating system||Processor architecture||Java 2 Platforms|
|Intel x86||Sun Java 2 SDK, Standard Edition, version 1.3.1 for Microsoft Windows|
|IBM Developer Kit for Windows, Java 2 Technology Edition, version 1.3.0|
|Sun Java 2 SDK, Standard Edition, version 1.4 for Microsoft Windows|
|Linux||Intel x86||Sun Java 2 SDK, Standard Edition, version 1.3.1 for Linux x86|
|IBM Developer Kit for Linux, Java 2 Technology Edition, version 1.3.0|
|Sun Java 2 SDK, Standard Edition, version 1.4 for Linux x86|
|Sun Solaris||SPARC||Sun Java 2 SDK, Standard Edition, version 1.3.1 for Solaris SPARC|
|Sun Java 2 SDK, Standard Edition, version 1.4 for Solaris SPARC|
|HP HP-UX||hp9000 PA-RISC||HP-UX SDK for the Java 2 platform, version 1.3.1 for hp9000 PA-RISC|
|IBM AIX||PowerPC||IBM Developer Kit for AIX, Java 2 Technology Edition, version 1.3.0|
The following table describes the combinations of operating system and Java 2 Platform used when testing the Eclipse SDK configurations. The status column indicates the level of testing: Primary means a full tested configuration; Secondary means a configuration which is only lightly tested; Untested means a configuration that has received no testing, but which should work. Note that the Linux GTK configuration is considered early access for the 2.0 release; it will be tested, but it is known in advance that it will not be of product quality in this release.
|Window system||Java 2 Platform
(see above table)
|Operating Environment||Testing Status|
|Win32||Windows on Intel x86||Windows 2000||Primary|
Linux on Intel x86
|RedHat Linux 7.2 x86||Primary|
|SuSE Linux 7.3 x86||Primary|
|Other Linux; kernel version 2.4.7, and XFree86 version 4.1.0||Untested|
|Solaris on SPARC||Sun Solaris 8 SPARC||Primary|
|HP-UX on hp9000 PA-RISC||HP-UX 11i hp9000||Primary|
|AIX on PowerPC||IBM AIX 5.1 on PowerPC||Primary|
|GTK||Linux on Intel x86||RedHat Linux 7.2 x86 GTK 2.0||Early access|
|SuSE Linux 7.3 x86 GTK 2.0||Early access|
|Other Linux; kernel version 2.4.7, and GTK 2.0||Early access; untested|
The Eclipse Platform 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 will be supported by the Eclipse SDK on all of the above operating environments; DBCS and BIDI locales will be supported by the Eclipse SDK only on Windows operating environments. [In the previous draft, internationalization was planned only for Windows operating environments.]
The Eclipse SDK will support the GB 18030, the new Chinese code page standard, on Windows 2000 and XP only. Note that GB 18030 also requires locale and character encoding support from the Java 2 Runtime Environment; this support is standard in version 1.4, and also available in some 1.3 JREs.
We will perform tests in German and Japanese locales.
The Eclipse SDK 2.0 is a development environment targeted at technical professionals - not an end user application. However the Eclipse SDK 2.0 tools will permit technical professionals who are working in English to build Hebrew/Arabic end user Java programs which are themselves not based on the Eclipse SDK. The BIDI support in the Eclipse SDK 2.0 allows a Java programmer to work with BIDI strings, code comments, etc but the Eclipse SDK itself is not designed to be localized for BIDI locales and its widget orientation can not be changed.
IMPORTANT: The above BIDI support is available only on Windows platforms.
Status of interim 1.0 APIs and plug-ins: Some of the Eclipse SDK APIs and plug-ins in 1.0 were marked as provisional (debug, for instance). These APIs and plug-ins will either appear in stable, finished form in the 2.0 release, or be removed. As anticipated (and advertised), these API changes will likely break 1.0 client plug-ins that made use of that particular API in its early form. Even if code appears to work with 2.0, it would still need to be completely reviewed to ensure that it abides by the final API contracts.
API Contract Compatibility: The Eclipse SDK 2.0 will be upwards contract-compatible with the Eclipse SDK 1.0 unless noted. This means that programs in full compliance with contracts specified in the Eclipse SDK 1.0 APIs will automatically be in full compliance with the Eclipse SDK 2.0 APIs. (API is construed broadly to include such things as plug-in extension points.) Downward contract compatibility is not supported. There is no guarantee that compliance with the Eclipse SDK 2.0 APIs would ensure compliance with the Eclipse SDK 1.0 APIs.
Binary (plug-in) Compatibility: The Eclipse SDK 2.0 will be upwards binary-compatible with the Eclipse SDK 1.0 unless noted. This means that plug-ins built for the Eclipse SDK 1.0 will continue to work correctly in the Eclipse SDK 2.0 without change. Downward plug-in compatibility is not supported. Plug-ins for the Eclipse SDK 2.0 are unlikely to be usable in the Eclipse SDK 1.0. Plug-ins with hard-coded references in their plug-in manifest file to 1.0 versions of prerequisite Eclipse Project plug-ins will not work in 2.0 as the plug-in version numbers will be incompatible.
Source Compatibility: The Eclipse SDK 2.0 will be upwards source-compatible with the Eclipse SDK 1.0 unless noted. This means that source files written to use the Eclipse SDK 1.0 APIs can be successfully compiled and run against the Eclipse SDK 2.0 APIs. Since source incompatibilities are easy to deal with, maintaining source compatibility is considered much less important than maintaining contract and binary compatibility. 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 2.0 will be upwards workspace-compatible with Eclipse SDK 1.0 unless noted. This means that workspaces and projects created with Eclipse SDK 1.0 can be successfully opened by Eclipse SDK 2.0 and upgraded to a 2.0 workspace. Individual plug-ins developed for Eclipse SDK 1.0 should provide similar upwards compatibility for their workspace metadata; plug-in developers are responsible for ensuring that their plug-ins recognize 1.0 metadata and process it appropriately. Note: the interim Eclipse SDK 1.0 plug-ins (ones with provisional APIs) are unlikely to automatically upgrade their metadata to 2.0. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. A workspace created (or opened) by Eclipse SDK 2.0 will be unusable with an earlier version of Eclipse SDK.
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 an earlier release. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.
JDT - Java development tooling
PDE - Plug-in development environment
For each subproject, the items listed reflect new features of the Eclipse Platform, or areas where existing features will be significantly reworked. Each item indicates the component affected by that work item (many items involve coordinated changes to several components).
Note that fixing bugs, improving test coverage, documentation, examples, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve significant changes to the Platform.
Improve Platform startup times. Eclipse Platform startup times 1.0 reflect the speed of XML parsing for plug-in manifest files. As the sheer number of available plug-ins can be expected to increase by an order of magnitude in the near future, we need a more scalable solution to this problem. An improvement in startup time will come with computing and caching the plug-in registry on disk.
[Replacement item] Improve Ant integration and the build story. In 1.0, Ant is not as well integrated into the workbench as it could be. In 2.0, we plan to make it more convenient to run Ant scripts from the Workbench, including ones not originally written for use inside the platform. We also plan to make the platform's build story more transparent, and allow Ant steps to be included. These changes impact the UI component as well. [formerly called Provide first-class Ant integration]
Improve serviceability. Several factors make it difficult in 1.0 to debug an Eclipse Platform that is failing in the field: startup failures are poorly diagnosed; error messages in the log sometimes contain little or no useful information; the internal plug-in log file is busy while the Platform is running, and gets erased as soon as the Platform is restarted. We plan to improve the startup sequence, eliminate unhelpful error messages, take steps to help identify which plug-in is the apparent source of an internal error, and ensure that the information in the internal logs is more readily accessible. These changes will also impact the UI component.
[Replacement for previously uncommitted item] Allow VCM control over rename/move/delete. VCM providers sometimes need tighter control over how project resources are manipulated in the local file system. For instance, a project directory might be a specially mounted remote file system located on a VCM server, and require special server communication in order to delete, move, or change the name of a resource. Or the VCM provider may track version history across move/renames. (Other clients would like a similar opportunity to veto inappropriate name changes to their resources; this is a different concern.) We will add a headless callback so that the relevant VCM provider will be able to control moves, renames, and deletes. These changes will affect the VCM component as well.
[Previously uncommitted item (revised)] Support unmanaged resources in managed projects. Workspace projects often contain files derived by processing other files; it is usually the case that these derived files should not be under VCM, even though the rest of the files in the project are. Workspace projects may also contain extra files or directories in which the VCM provider stores metadata; however, these files are not of direct interest to either the user or to regular plug-ins. There needs to be some means of dealing with these; depending on the solution, this may require support from the UI as well as Core.
[New item] Improve support for product branding. We will make it easier to furnish custom product information such as splash screens, product startup configuration, distinctive icons for product branding, product-specific preference settings, etc.
Redesign plug-in installation and update story. The 1.0 concepts of component and configuration will be replaced with a new concept called a feature. Features define the packaging structure for a group of related plug-ins, plug-in fragments, and optionally non-plug-in files. This change impacts the Core component and the PDE subproject as well.
Improve installer flexibility. The standard Platform installer will be more flexible and support alternate packaging and site management schemes: structured site map for discovering available updates; improved granularity of downloads; accommodate native installers; feature-specific custom installers packaged with feature and executed during feature installation.
Improve accessibility. Applications selling to the US Government market are required to meet minimum accessibility guidelines (Section 508). The workbench and its standard views and wizards must meet minimum accessibility guidelines, including mouse-less operation. The Eclipse Platform needs to enable other client plug-ins to meet accessibility guidelines too. This change also impacts the SWT component.
Improve editor management. Users are finding it difficult to work with many editors open simultaneously in the Eclipse SDK 1.0 workbench, all seemingly stemming from the way editors are currently managed. The workbench's approach to editor management will be reviewed and revised to improve usability.
Improve interaction between editors and views. There are some unfortunate interactions between editors and views in Eclipse SDK 1.0 that make it difficult for views to serve as "secondary windows" to an editor. Among other things, this leads to poor integration of standard views. The workbench's current approach to editors and views will be reviewed and revised to facilitate interaction and improve integration.
Allow context menu contributions in Outline view. In Eclipse SDK 1.0, clients have no control over the standard Outline view's popup context menu. This will be addressed so that clients will be able to make contributions to this menu.
Improve usability re: losing context. Some users have reported getting lost in the UI and having to close all open editors and perspectives to get their workbench back into a familiar state. The current approach will be reviewed and revised to improve usability.
Improve the Task view. The standard Task view will be improved in the following areas: performance and usability for large numbers of items in the view; context-sensitive help; and making contributions to the view's context menu.
Add support for working sets. In 1.0, all resources in the workspace are equally accessible. The workbench will let the user define working sets of resources, suitable for providing more restricted contexts for browsing, searching, and the like.
[Previously uncommitted item (revised)] Improve usability of project natures. In Eclipse SDK 1.0, project natures are secretly configured by the plug-ins that define them, leading to problems and blind spots when projects have other natures as well. We will enrich the underlying support for natures by adding declarative constraints between natures, and expose them to the user in the form of "capabilities" which the user may (re-)configure their project with. These changes also affect the Core component.
[Previously uncommitted item] Improve consistency of saving workbench state. In Eclipse SDK 1.0, there are a number of instances where user-configurable UI settings are not being persisted between sessions. The UI will provide better support for saving important UI state.
[New item] Improve support for file encodings. Editors and other tools need to have the correct file encoding in order to read or write text files. In Eclipse SDK 1.0, everything uses the default file encoding for the current locale. We will improve this for Eclipse SDK 2.0.
[New item] Improve support for clipboard-based cut/copy/paste. There are several places in the workbench where cut/copy/paste are not enabled where they should be. The UI will allow clients to supply these actions so they work as expected.
Support additional window systems. Add support for new window system: GTK. Port Motif-based implementation to other operating systems: AIX, HP-UX, Solaris. Foster and encourage efforts to port to other window systems.
[Revised item] Support GB18030. GB 18030 is a new Chinese code page standard. Products shipping into the China market are required to support this new standard. The GB 18030 character encoding support is standard in Java 2 Runtime Environment version 1.4, and also available in some 1.3 JREs.
Utilize Windows native Unicode support. The SWT implementation will use native Unicode support on all Windows operating systems that support it (NT, 2000, XP).
Improve Motif appearance and performance. In 1.0, support for the Motif window system lags behind that of Windows. We plan to improve the appearance and performance of SWT on Motif.
[New item] Remove internal call to XinitThreads. In 1.0 on Motif, the internal call that SWT makes on XinitThreads prevents drag and drop, and printing from working. In 2.0, we will find a way to remove this impediment.
Provide an open VCM story. Eclipse SDK 1.0 includes CVS repository support, but has no official VCM API that allows other version and configuration management systems to integrate into the Platform. We will provide a simple API, extension points, and usage guidelines so that VCM providers can adapt their repositories and integrate VCM product-specific UI elements into the Eclipse SDK UI.
[Revised item] Improve CVS repository integration. In addition to converting the existing CVS repository adapter to the new VCM API, CVS support will be improved, including: support for CVS modules so that the platform can be connected to existing CVS repositories; support for CVS patch facility so that CVS users can capture changes to a project in a tangible form that can be submitted to others or archived (this also involves the compare infrastructure); correct classification of text and binary files.
Add non-versioning WebDAV repository support. We plan to build a simple repository adapter for non-versioning WebDAV servers. This will allow users to share their files via any WebDAV compliant server. This also affects the Core component (target management API).
The Help component organizes help contributions and presents them to the user. The following items are committed for 2.0:
Simplify contribution mechanism. Based on feedback on 1.0, we plan to rework and simplify the help contribution mechanism. Online documentation created for 1.0 will need to be converted for 2.0.
[Revised item] Use a separate web browser to present help. We will use an external web browser launched in a separate window to present all documentation and online help. This will allow help to be presented in a non-modal way. We will support one help browser for each target environment. Refer to the table in the Help Component for additional information on supported browsers.
Support live help. We will support the ability to trigger developer-supplied actions as a result of navigating a link in the online documentation. The actions will execute within the Eclipse Platform environment.
[Revised item] Enable help servers. It is often desirable to be able to make plug-in documentation accessible to users that do not have the Eclipse Platform installed. We will support configurations where online documentation can be hosted on a web server and viewed through a regular web browser. [The former "Info Center" item has been merged with this one.]
[Revised item] Support standalone help. Developers will be able to reuse the Eclipse Platform help function even in products that are not built using the Eclipse Platform itself.
[Previously uncommitted item (revised)] Add help search support. We will provide the ability to search help documentation, based on Lucene. Stemmers will be used when available for the language; for example, the Porter stemming algorithm is used for English.
Stabilize Debug API. In Eclipse SDK 1.0, all debug APIs were considered provisional and incomplete. The Debug APIs will appear in finished, stable form.
Add support for debugging procedural languages. The Debug component will be extended to enable debuggers to be written for procedural languages (e.g., C) which get compiled to machine code and run on standard hardware.
Add launch configurations. The Debug component will add a general mechanism and UI for the user to define launch configurations describing how something is to be launched (e.g., command line options).
[New item] Remove Scripting component. In Eclipse SDK 1.0, the scripting support was provisional and incomplete. It is now clear that we will not become real in the 2.0 timeframe. The Scripting component will be withdrawn from the Eclipse Platform (it may be re-introduced in a later release).
N.B. The following is the list of important Eclipse Platform subproject work items which we are presently unable to commit to for the 2.0 release. Wherever possible, we will try to complete these items. Depending on how things work out, we should be able complete some of them. However, we cannot promise that we will complete any of them, and it would be unwise to gamble otherwise. Items not completed for 2.0 will carry over to the planning of the next release. We will revise this 2.0 plan as soon as we can definitively commit to any of them.
Add support for non-local files. It is expensive to set up a workspace project containing a large number of files that normally reside on remote server or file system. Core has a basic mechanism that permits the workspace to contain placeholders for files and folders necessarily resident in the local file system. The Core mechanism will be augmented so that VCM can use it to hook it to retrieve files from a remote server or file system on demand. The UI component is also affected.
Improve undo/redo in workbench. In Eclipse SDK 1.0, undo and redo are poorly supported for workbench actions, and it is still far too easy for a user to lose work. We will consider providing an undo/redo service that will help decrease the risk of inadvertently losing work.
Provide a standard Console view. In Eclipse SDK 1.0, there is a proliferation of consoles furnished by clients (including JDT, PDE, Ant). The workbench will supply a standard Console view; clients will be encouraged to use it instead of providing their own. These changes will affect the UI component.
[Deleted item] Improve support for cheat sheets. In Eclipse SDK 1.0, the Welcome editor is an example of a cheat sheet. A cheat sheet is an instance of a simple kind of workflow support. We will continue to evolve the mechanisms behind cheat sheets, including adding standard API for creating actions. These changes will affect the UI component. [This has turned out to require a major effort, so we are removing this uncommitted item from the 2.0 plan.]
[Deleted item] Provide project interchange mechanism. We will provide a way to export the resources in one of more workspace projects to an archive file that it can be saved for posterity or imported to another workspace. This affects the Core and UI components. [A consequence of the new VCM story is that we do not need to provide a special mechanism for project interchange. Therefore we are removing this uncommitted item from the 2.0 plan.]
[Deleted item] Provide additional internationalization support. We will enable the Eclipse Platform to provide internationalization support for additional locales on some Motif operating environments. This affects the SWT component. [We have added support for additional locales (see the Internationalization section in this plan for more details). This uncommitted item is redundant, so we are removing it from the 2.0 plan.]
[New item] Improve local resource history. The workspace local resource history mechanism keeps recent copies of modified or deleted files in order to help save the user from losing data in common situations. In 1.0, many UI actions that the user would reasonably expect to grow the history are not doing so, and there is no obvious way to recover a saved state of a file once it has been deleted. We plan to make the history facility more reliable and helpful for 2.0.
[New item] Add ftp repository support. We plan to build a simple repository adapter for ftp servers. This also affects the Core component (target management API).
(End of items for Eclipse Platform subproject.)
Reduce memory footprint for Java builder. The internal data structures of the Java incremental compilation mechanism is using more memory than necessary or reasonable. By fundamentally changing the approach to how incremental builds are done we expect to substantially reduce the memory footprint without significantly increasing incremental compile times.
Improve Java search. Java reference searches in Eclipse SDK 1.0 are limited to named types in source files. This will be addresses so to make it possible to find references in JAR libraries, and to distinguish read and write accesses to fields.
Improve code assist. A number of changes will improve usability of code assist: including method argument names and types as hints; suggesting variable names; honoring visibility constraints dictated by the context.
Upgrade Eclipse Java compiler to be compliant with version 1.4 of the Java 2 Platform. A new assertion feature was added in 1.4, and there were a few clarifications in obscure corners of the Java language specification. The Eclipse Java compiler will be upgraded to support 1.4, but will continue to support 1.3 via an option setting.
Improve build classpath. By adding a mechanism for explicitly exporting libraries on a project's build classpath to downstream projects, it becomes possible to have a library project (one with a JAR and no source folder) that can stand in for a project containing source code. This change enables large scale development where source code is contained in multiple, related Java projects, by providing possibilities other than having all the source code projects in the workspace at all times (expensive to build). Plug-in development is a direct beneficiary.
Improve accessibility. Applications selling to the US Government market are required by law to meet minimum accessibility guidelines (Section 508). The JDT UI must meet minimum accessibility guidelines, and enable its client plug-ins to meet accessibility guidelines as well.
[Revised item] Improve Java editor. Rework menu bar contributions and context menu to improve usability; add a template facility with variable substitution; add navigation to a method's super implementation; add bracket matching; add error clueing; add line/column numbers.
Improve refactoring. Implement additional refactorings: extract variable, inline temporary, push-up field/method, change method signature. Support reference updates in strings and comments for move/rename refactorings.
[Revised item] Improve package browsing: Provide a more package-centric view for browsing. In 1.0, the Packages view presents packages grouped by their containers. We will continue to support the existing container based presentation; in addition, we are exploring alternatives. We will also add support to show the structure of a compilation unit in the Packages view.
Facilitate string externalization. Add a wizard that allows the user to externalizing string literals in Java source code into standard Java resource bundles.
[Revised item] Allow runtime parameters to the configured. Using the new launch configuration mechanism provided by the Platform Debug component will allow the working directory, runtime classpath, boot classpath, extension directories, and other VM-type specific launch parameters to be configured.
[Revised item] Support hot code replace when debugging compliant Java 1.4 targets. JDPA for version 1.4 of the Java 2 Platform allow a class to be updated while under the control of the debugger. In 1.0, this kind of support was only available for IBM J9 targets. The Java debugger will be changed to support both. Provide smart drop to frame that only removes affected frames from the stack.
Enable JSP debugging with JPDA. The Java debugger will enable JSP debugging via a flexible source lookup algorithm and breakpoint setting mechanism.
Add debugger support for step filtering. The Java debugger will avoid stepping into any class mentioned on a user-specified exclusion list.
Improve data inspectors. We will improve support in the debugger for inspecting objects, including running an object's toString method to obtain a readable string that may be more meaningful to the user.
[Previously uncommitted item] Add API for Java abstract syntax tree. In Eclipse SDK 1.0, refactoring uses compiler internals for parsing and walking the abstract syntax trees (ASTs) for Java source code. We will add API for creating and manipulating ASTs that can serve as the basis for other clients like refactoring.
[Previously uncommitted item] Support field watchpoints. We will add debugger support for field watchpoints.
[Previously uncommitted item] Support editor key bindings. Add support for user-configurable key bindings in the Java editor. This requires changes in the Platform UI component.
[New item] Add support for JUnit. We will include special tooling for the popular JUnit unit test framework to facilitate authoring and running of JUnit test cases.
[New item] Add support for Javadoc generation. We will add an action for generating Javadoc for a Java project (note: requires a standard JDK).
[New item] Improve navigating to Javadoc. We will add quick keyboard navigation from names in Java source code to the corresponding Javadoc, including the API Javadoc for names declared in libraries.
N.B. The following is the list of important JDT subproject work items which we are presently unable to commit to for the 2.0 release. Wherever possible, we will try to complete these items. Depending on how things work out, we should be able complete some of them. However, we cannot promise that we will complete any of them, and it would be unwise to gamble otherwise. Items not completed for 2.0 will carry over to the planning of the next release. We will revise this 2.0 plan as soon as we can definitively commit to any of them.
Support conditional breakpoints. We will add debugger support for conditional breakpoints with simple conditions, including simply object identity tests of the form "this == id" sufficient for object breakpoints.
(End of items for Eclipse JDT subproject.)
Improve accessibility. Applications selling to the US Government market are required by law to meet minimum accessibility guidelines (Section 508). The PDE UI must meet minimum accessibility guidelines, and enable its client plug-ins to meet accessibility guidelines as well.
Support revamped install and update story. PDE contains support for building the deployable form of a plug-in, or set of plug-ins. We will update PDE to support the revised install and update story.
Improve support for large scale multi-project plug-in development. We will improve support for large scale development efforts involving multiple plug-ins spread across several projects in the workspace.
[New item] Provide PDE API. We will add an extension point to allow plug-ins to contribute wizards from creating new extensions in the PDE Plug-in Manifest editor, and expose PDE API needed by clients that provide such wizards.
[New item] Source builds. In 1.0, the process used to create new Eclipse SDK drops from sources is only usable by the original development team. In 2.0, the magic will be removed and replaced by generally available scripts that anyone can use to build Eclipse SDK drops from sources.
(End of items for Eclipse PDE subproject.)