<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>

<head>

   <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">

   <meta name="Author" content="Eclipse Project PMC">

   <meta name="GENERATOR" content="Microsoft FrontPage 4.0">

   <meta name="ProgId" content="FrontPage.Editor.Document">

   <title>Eclipse Project 2.0 Plan</title>

   <link rel="stylesheet" href="../default_style.css" type="text/css">

</head>

<body>



<h1>

Eclipse Project<br>

DRAFT 2.0 Plan</h1>

Last revised Wednesday, February 14, 2002 [<u><font color="#008000">noting changes
since previous draft plan Friday, December 21, 2001</font></u>]
<p><i>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to the </i><a href="mailto:eclipse-dev@eclipse.org">eclipse-dev@eclipse.org</a>
<i>developer mailing list.</i></p>

<p>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. 
<p>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. 
<p>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 <a href="http://www.eclipse.org/eclipse/index.html" target="_top">subproject 
  and component web pages</a> and <a href="http://www.eclipse.org/mail/index.html" target="_top">developer 
  mailing list archives</a> 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 <a href="http://dev.eclipse.org/bugs/">bug 
  database</a>; the &quot;Target Milestone&quot; field reflects when a work item 
  will become available in the main development stream. 
<p>[<font color="#008000"><u>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.</u></font>] 
<h2>Release deliverables</h2>

<p>The release deliverables are:

<ul>

  <li>Source code release for Eclipse Project, available as versions tagged &quot;R2_0&quot; 
    in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS repository</a>.</li>

  <li>Eclipse Project SDK (includes Platform, JDT, and PDE source zips)

    (downloadable).</li>

  <li>Eclipse Platform runtime binary distribution (downloadable).</li>

  <li>JDT runtime binary distribution (downloadable).</li>

  <li>Eclipse SDK Examples (downloadable).</li>

</ul>

<h2>Release milestones</h2>

<p>The release milestones are:</p>

<ul>

  <li>December 7, 2001 - milestone 0 - stable build reflecting progress</li>

  <li>December 21, 2001 - milestone 1 - stable build reflecting good progress</li>

  <li>January 25, 2002 - milestone 2 - stable build reflecting significant

    progress</li>

  <li>February 15, 2002 - milestone 3 - stable build reflecting significant

    progress [<u><font color="#008000">former initial development freeze</font></u>]</li>

  <li>[<u><font color="#008000">new milestone</font></u>] March 15, 2002 -
    milestone 4 - stable build reflecting significant

    progress</li>

  <li>[<u><font color="#008000">new milestone</font></u>] April 5, 2002 - milestone
    5 - stable build reflecting significant

    progress</li>

  <li>[<u><font color="#008000">new milestone</font></u>] April 26, 2002 - milestone
    6 - stable build - feature complete -

    initial development&nbsp; freeze</li>

</ul>

<p>

The 2.0 release is targeted for May 2002 [<u><font color="#008000">formerly
April</font></u>]. 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.</p>

<h2>

Target Operating Environments</h2>



<p>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.</p>

<p>We plan to test and validate the Eclipse SDK 2.0 on the most up-to-date Java 
  2 Platform implementations available. These are:</p>

<table border="1" width="91%">

  <tr>

    <td width="19%"><b>Operating system</b></td>

    <td width="24%"><b>Processor architecture</b></td>

    <td width="73%"><b>Java 2 Platforms</b></td>

  </tr>

  <tr>

    <td width="19%" rowspan="3">Microsoft<br>

      Windows</td>

    <td width="24%" rowspan="3">Intel x86</td>

    <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.3.1 for

    Microsoft Windows</td>

  </tr>

  <tr>

    <td width="73%">IBM Developer Kit for Windows, Java 2 Technology Edition, version 1.3.0</td>

  </tr>

  <tr>

    <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Microsoft 
      Windows</td>

  </tr>

  <tr>

    <td width="19%" rowspan="3">Linux</td>

    <td width="24%" rowspan="3">Intel x86</td>

    <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.3.1 for Linux x86</td>

  </tr>

  <tr>

    <td width="73%">IBM Developer Kit for Linux, Java 2 Technology Edition, version 1.3.0</td>

  </tr>

  <tr>

    <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Linux x86</td>

  </tr>

  <tr>

    <td width="19%" rowspan="2">Sun Solaris</td>

    <td width="24%" rowspan="2">SPARC</td>

    <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.3.1 for Solaris

      SPARC</td>

  </tr>

  <tr>

    <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Solaris 
      SPARC</td>

  </tr>

  <tr>

    <td width="19%">HP HP-UX</td>

    <td width="24%">hp9000 PA-RISC</td>

    <td width="73%"><span class="header">HP-UX SDK for the Java 2 platform,

      version 1.3.1 for hp9000 PA-RISC</span></td>

  </tr>

  <tr>

    <td width="19%">IBM AIX</td>

    <td width="24%">PowerPC</td>

    <td width="73%">IBM Developer Kit for AIX, Java 2 Technology Edition, version 1.3.0</td>

  </tr>

</table>

<p><span class="header">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; </span>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.</p>

<table border="1" width="91%">

  <tr>

    <td width="11%"><b>Window system</b></td>

    <td width="28%"><b>Java 2 Platform<br>

      (see above table)</b></td>

    <td width="42%"><b>Operating Environment</b></td>

    <td width="19%"><b>Testing Status</b></td>

  </tr>

  <tr>

    <td width="11%" rowspan="5">Win32</td>

    <td width="28%" rowspan="5">Windows on Intel x86</td>

    <td width="42%">Windows 2000</td>

    <td width="19%">Primary</td>

  </tr>

  <tr>

    <td width="42%">Windows XP</td>

    <td width="19%">Primary</td>

  </tr>

  <tr>

    <td width="42%">Windows ME</td>

    <td width="19%">Secondary</td>

  </tr>

  <tr>

    <td width="42%">Windows 98SE</td>

    <td width="19%">Secondary</td>

  </tr>

  <tr>

    <td width="42%">Windows NT</td>

    <td width="19%">Secondary</td>

  </tr>

  <tr>

    <td width="11%" rowspan="6">Motif</td>

    <td width="28%" rowspan="3">&nbsp;

      <p>Linux on Intel x86</p>

      <p>&nbsp;</td>

    <td width="42%">RedHat Linux 7.2 x86</td>

    <td width="19%">Primary</td>

  </tr>

  <tr>

    <td width="42%">

SuSE Linux 7.3 x86</td>

    <td width="19%">Primary</td>

  </tr>

  <tr>

    <td width="42%">Other Linux; kernel version 2.4.7, and XFree86 version 4.1.0</td>

    <td width="19%">Untested</td>

  </tr>

  <tr>

    <td width="28%">Solaris on SPARC&nbsp;</td>

    <td width="42%">Sun Solaris 8 SPARC</td>

    <td width="19%">Primary</td>

  </tr>

  <tr>

    <td width="28%">HP-UX on hp9000 PA-RISC</td>

    <td width="42%">HP-UX 11i hp9000</td>

    <td width="19%">Primary</td>

  </tr>

  <tr>

    <td width="28%">AIX on PowerPC</td>

    <td width="42%">IBM

AIX 5.1 on PowerPC</td>

    <td width="19%">Primary</td>

  </tr>

  <tr>

    <td width="11%" rowspan="3">GTK</td>

    <td width="28%" rowspan="3">Linux on Intel x86</td>

    <td width="42%">RedHat Linux 7.2 x86 GTK 2.0</td>

    <td width="19%"><i>Early access</i></td>

  </tr>

  <tr>

    <td width="42%"> SuSE Linux 7.3 x86 GTK 2.0</td>

    <td width="19%"><i>Early access</i></td>

  </tr>

  <tr>

    <td width="42%">Other Linux; kernel version 2.4.7, and GTK 2.0</td>

    <td width="19%"><i>Early access; untested</i></td>

  </tr>

</table>

<h4>

Internationalization</h4>

<p> 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.</p>



<p>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. [<font color="#008000"><u>In the previous 
  draft, internationalization was planned only for Windows operating environments.</u></font>]
<p>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.
<p>We will perform tests in German and Japanese locales.

<h4>

BIDI support</h4>

<p> 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.</p>

<p>IMPORTANT: The above BIDI support is available only on Windows platforms.</p>

<h2>

Compatibility with Previous Release</h2>

The Eclipse SDK 2.0 will be upwards compatible with the Eclipse SDK 1.0 to the 
greatest extent possible. We anticipate a small number of areas where slavishly 
maintaining compatibility would not be in the best interests of the Platform or 
its clients. All such exceptions will be noted in the 2.0 release notes so that 
clients can assess the impact of these changes on their plug-ins and products. 
<p><b>Status of interim 1.0 APIs and plug-ins</b>: 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.</p>

<p><b>API Contract Compatibility:</b> 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. 
<p><b>Binary (plug-in) Compatibility:</b> 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. 
<p><b>Source Compatibility:</b> 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. 
<p><b>Workspace Compatibility:</b> 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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp;&nbsp;

<p><b>Non-compliant usage of API's</b>: All non-API methods and classes, and certainly 
  everything in a package with &quot;internal&quot; 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 <i><a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">How 
  to Use the Eclipse API</a></i> for information about how to write compliant 
  plug-ins. 
<h2> Eclipse Project Subprojects</h2>

The Eclipse Project consists of 3 subprojects. Each subproject

is covered in its own section:

<blockquote><font size=+0><a href="#Eclipse Platform subproject">Eclipse Platform</a></font>

<br><font size=+0><a href="#Java development tooling (JDT) subproject">JDT - Java development tooling</a></font>

<br><font size=+0><a href="#Plug-in development environment (PDE) subproject">PDE - Plug-in development environment</a></font></blockquote>

<p>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). 
<p>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.

<h3>

<a name="Eclipse Platform subproject">Eclipse Platform subproject</a></h3>

The following items 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 (some items involve coordinated

changes to several components). Additional uncommitted items affecting these

components are listed in the <a href="#Uncommitted Items">Uncommitted Items</a>

section at the end.

<h4>

Platform Core component</h4>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core-home/main.html">Platform

Core component</a> covers most of the Platform's non-UI infrastructure,

including the basic plug-in mechanism, resources in the workspace. The following

items are committed for 2.0:

<blockquote><b><a name="Improve Platform startup times">Improve Platform

startup times</a>.</b> 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.
  <p>[<u><font color="#008000">Replacement item</font></u>] <b><a name="Improve Ant integration and the build story">Improve 
    Ant integration and the build story</a>.</b> 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 <a name="Improve Ant integration"><b>Provide 
    first-class Ant integration</b></a><b>]</b> 
  <p><a name="Improve serviceability"><b>Improve serviceability</b></a><b>.</b>

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.<p>[<font color="#008000"><u>Replacement
  for previously uncommitted item</u></font>] <b><a name="Allow VCM control over rename/move/delete">Allow VCM control over
  rename/move/delete</a>.</b> 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.

  <p>[<u><font color="#008000">Previously uncommitted item (revised)</font></u>] <a name="Support unmanaged resources in managed projects"><b>Support

unmanaged resources in managed projects</b></a><b>.</b> 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.</p>

  <p>[<u><font color="#008000">New item</font></u>] <b><a name="Improve support for product branding">Improve
  support for product branding</a>.</b>  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.</blockquote>



<h4>

Installation and Update component</h4>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-update-home/main.html"> Installation and Update component</a> is responsible for installing and upgrading the Eclipse

Platform in the field. Eclipse SDK 1.0 contains an early version

of this component; it will be thoroughly reworked for 2.0. The following items

are committed for 2.0:

<blockquote>

  <p><b><a name="Redesign plug-in install and update story">Redesign

plug-in installation and update story</a>.</b>&nbsp; The 1.0 concepts of <i>component</i>

  and <i>configuration</i> will be replaced with a new concept called a <i>feature</i>.

  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.</p>

  <p><b><a name="Improve installer flexiblilty">Improve installer </a><a name="Improve installer flexiblilty">flexibility</a>.</b>

  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.</p>

</blockquote>



<h4>

Platform UI component</h4>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/main.html">Platform

UI component</a> provides the generic workbench UI for the Eclipse Platform. The following

items are committed for 2.0:

<blockquote><b><a name="Improve accessibility - UI">Improve accessibility</a>.</b> 

  Applications selling to the US Government market are required to meet minimum 

  accessibility guidelines (<a href="http://www.section508.gov/" target="_top">Section 

  508</a>). 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. 

  <p><b><a NAME="Improve editor management">Improve editor management</a>.</b>

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.

<p><b><a name="Improve interaction between editors and views">Improve

interaction between editors and views</a>.</b> 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.

<p><b><a name="Allow context menu contributions in Outline view">Allow

context menu contributions in Outline view</a>.</b> 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.

<p><b><a name="Improve usability re: losing context">Improve usability

re: losing context</a>.</b> 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.

<p><b><a name="Improve the Task view">Improve the Task view</a>.</b>  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.<p><b><a name="Add support for working sets">Add support for working

  sets</a>.</b>  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.

<p>[<u><font color="#008000">Previously uncommitted item (revised)</font></u>] <a name="Improve usability of project natures"><b>Improve

usability of project natures</b></a><b>.</b> 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 &quot;capabilities&quot; which the user
may (re-)configure their project with. These

changes also affect the Core component.

<p>[<u><font color="#008000">Previously uncommitted item</font></u>] <a name="Improve consistency of saving workbench state"><b>Improve

consistency of saving workbench state</b></a><b>.</b> 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.

  <p>[<u><font color="#008000">New item</font></u>]
  <b><a name="Improve support for file encodings">Improve support for file encodings</a>.</b> 
  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.<p>[<u><font color="#008000">New
  item</font></u>] <b><a name="Improve support for clipboard-based cut/copy/paste">Improve
  support for clipboard-based cut/copy/paste</a>.</b> 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.</blockquote>



<h4>

SWT component</h4>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html">SWT 
component</a> is the low-level widget toolkit used in the Eclipse Platform. The 
following items are committed for 2.0: 
<blockquote>

  <p><b><a name="Port to other window systems">Support additional&nbsp; window

  systems</a>.</b> 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.

  <p>[<u><font color="#008000">Revised item</font></u>] <a name="Support GB18030"><b>Support 
    GB18030</b></a><b>.</b> 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.
  <p><b><a name="Utilize native Unicode support">Utilize

  Windows native Unicode support</a>.</b>  The SWT implementation will use

  native Unicode support on all Windows operating systems that support it (NT,

  2000, XP).<p><b>Improve Motif appearance and performance.</b> 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.
  <p><font FACE="Times New Roman" COLOR="#000000">[</font><u><font FACE="Times New Roman" COLOR="#008000">New
  item</font></u><font FACE="Times New Roman" COLOR="#000000">] <b>Remove
  internal call to XinitThreads</b>. 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.</font></p>

</blockquote>



<h4>

VCM component</h4>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-vcm-home/main.html"> VCM component</a> provides version and configuration management for projects

in the workspace and attendant team support. The following items are committed for 2.0:

<blockquote><a name="Provide VCM API"><b>Provide an open VCM </b></a><b><a name="Provide VCM API">story</a>.</b> 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.
  <p>[<u><font color="#008000">Revised item</font></u>] <a name="Improve CVS repository integration"><b>Improve 
    CVS repository integration</b></a><b>.</b> 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.
</blockquote>



<ul><a name="Add mechanism for validating edits and saves"><b>Add mechanism

for validating edits and saves</b></a><b>.</b> Some VCM providers require a "heads up" when the user starts

to change the contents of a file open in an editor (e.g., to allow the file to

  be checked out and locked), or when the user is about to save the changed contents

back to disk. We will add a callback so that the relevant VCM provider will be

  able to register for advance notification with an opportunity to veto. This

  change also affects the UI and Core components.<p> <b><a name="Add non-versioning WebDAV repository support">Add non-versioning
  WebDAV repository
  support</a>.</b> 

  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).</p>

</ul>



<h4>

Help component</h4>



<p>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-help-home/main.html"> Help component</a> organizes help contributions and presents them to the

user. The following items are committed for 2.0:</p>

<blockquote><p><b><a name="Simplify contribution mechanism">Simplify

  contribution mechanism</a>.</b> 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.<p>[<u><font color="#008000">Revised
  item</font></u>] <a name="Use a separate web browser to present help"><b>Use

a separate web browser to present help</b></a><b>.</b> 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.&nbsp;
  We will support one help browser for each target environment.&nbsp; Refer to the
  <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-help-home/eclipse_project_plan_2_0_supported_browsers.html">table</a>
  in the Help Component for additional information on supported browsers.
  <p><b><a name="Support live help">Support live help</a>.</b> 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.
  <p>[<u><font color="#008000">Revised item</font></u>] <b><a name="Allow remote help content">Enable 
    help server</a>s.</b> 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. [<u><font color="#008000">The former 
    &quot;Info Center&quot; item has been merged with this one.</font></u>] 
  <p>[<u><font color="#008000">Revised item</font></u>] <b><a name="Support standalone help">Support 
    standalone help</a>.</b> Developers will be able to reuse the Eclipse Platform 
    help function even in products that are not built using the Eclipse Platform 
    itself.&nbsp; 
  <p>[<u><font color="#008000">Previously uncommitted item (revised)</font></u>]
  <a name="Add help search support"><b>Add help search support</b></a><b>.</b>

 We will provide the ability to search help documentation, based on <a href="http://jakarta.apache.org/lucene/docs/index.html">Lucene</a>.
  Stemmers will be used when available for the language; for example, the Porter
  stemming algorithm is used for English.

</blockquote>



<h4>

Platform Debug component</h4>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-debug-home/main.html">Platform

Debug component</a> provides generic Core and UI for launching, running, and debugging

programs. The following items are committed for 2.0:

<blockquote><a name="Stabilize Debug API"><b>Stabilize Debug API</b></a><b>.</b>

In Eclipse SDK 1.0, all debug APIs were considered provisional and incomplete.

The Debug APIs will appear in finished, stable form.</blockquote>



<blockquote><a name="Add support for debugging procedural languages"><b>Add

support for debugging procedural languages</b></a><b>.</b> 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.

<p><a name="Add launch configurations"><b>Add launch configurations</b></a><b>.</b>

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).</blockquote>



<h4>

Scripting component</h4>

The <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-scripting-home/main.html">Scripting
component</a> provides general support for scripting (other than Ant). The following
item is committed for 2.0:&nbsp;

<blockquote>
  <p>[<u><font color="#008000">New item</font></u>] <b><a name="Remove Scripting component">Remove
  Scripting component</a>.</b>

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).</p>
</blockquote>



<h4>

<a name="Uncommitted Items">

Uncommitted Items</a> (Eclipse Platform subproject)</h4>

<p><i>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.</i></p>

<ul>
  <p> <a name="Add support for non-local files"><b>Add support for non-local files</b></a><b>.</b> 
    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.
  <p> <a name="Improve undo/redo in workbench"><b>Improve undo/redo in workbench</b></a><b>.</b> 
    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. 
  <p><a name="Provide a standard Console view"><b>Provide a standard Console view</b></a><b>.</b> 
    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. 
  <p>[<u><font color="#008000">Deleted item</font></u>] <a name="Improve support for cheat sheets"><b>Improve 
    support for cheat sheets</b></a><b>.</b> 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. [<font color="#008000"><u>This has turned out 
    to require a major effort, so we are removing this uncommitted item from the 
    2.0 plan.</u></font>]
  <p>[<u><font color="#008000">Deleted item</font></u>] <b><a name="Provide project interchange mechanism">Provide 
    project interchange mechanism</a>.</b> 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.&nbsp; [<font color="#008000"><u>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.</u></font>]
  <p>[<u><font color="#008000">Deleted item</font></u>] <b><a name="Provide additional internationalization support">Provide 
    additional internationalization support</a>.</b>&nbsp; We will enable the 
    Eclipse Platform to provide internationalization support for additional locales 
    on some Motif operating environments. This affects the SWT component. [<font color="#008000"><u>We 
    have added support for additional locales (see the Internationalization section 
    in this plan for more details).&nbsp; This uncommitted item is redundant, 
    so we are removing it from the 2.0 plan.</u></font>]
  <p>[<u><font color="#008000">New item</font></u>] <b><a name="Improve local resource history">Improve 
    local resource history</a>.</b> 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.
  <p>[<u><font color="#008000">New item</font></u>] <b><a name="Add ftp repository support">Add 
    ftp repository support</a>.</b> We plan to build a simple repository adapter 
    for ftp servers. This also affects the Core component (target management API).</p>
</ul>



<p>(End of items for Eclipse Platform subproject.)



<h3>

<a name="Java development tooling (JDT) subproject">Java development tooling (JDT) subproject</a></h3>

<a href="http://www.eclipse.org/jdt/index.html">

Java development tooling</a> (JDT) implements a Java IDE based on the Eclipse

Platform.

The following committed items reflect new features of JDT, or areas where existing

features will be significantly reworked.

<blockquote><a name="Reduce memory footprint for Java builder"><b>Reduce

memory footprint for Java builder</b></a><b>.</b> 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.

<p><b><a name="Improve Java search">Improve Java search</a>.</b> 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.

  <p><a name="Improve code assist"><b>Improve code assist</b></a><b>.</b> 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.

<p><b><a name="Upgrade Eclipse Java compiler to be compliant with version 1.4 of the Java 2 Platform">Upgrade

Eclipse Java compiler to be compliant with version 1.4 of the Java 2 Platform</a>.</b>

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.

<p><b><a name="Improve build classpath">Improve build classpath</a>.</b>

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.

  <p><b><a name="Improve accessibility - JDT">Improve accessibility</a>.</b> Applications 

    selling to the US Government market are required by law to meet minimum accessibility 

    guidelines (<a href="http://www.section508.gov/" target="_top">Section 508</a>). 

    The JDT UI must meet minimum accessibility guidelines, and enable its client 

    plug-ins to meet accessibility guidelines as well. 

  <p>[<u><font color="#008000">Revised item</font></u>] <a name="Improve Java editor"><b>Improve Java editor</b></a>. 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.

<p><b><a name="Improve refactoring">Improve refactoring</a>.</b> 

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.

<p>[<u><font color="#008000">Revised item</font></u>] <b><a name="Improve refactoring">Improve package

browsing</a></b>: 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.

<p><b><a name="Facilitate string externalization">Facilitate

</a><a name="Facilitate string externalization">string

externalization</a></b><b>.</b> Add a wizard that

allows the user to

externalizing string literals in Java source code into standard Java resource bundles.

<p>[<u><font color="#008000">Revised item</font></u>] <b><a name="Allow runtime parameters to the configured">Allow runtime
parameters to the configured</a>.</b> 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.

  <p>[<u><font color="#008000">Revised item</font></u>] <b><a name="Support hot code replace when debugging JDK 1.4 targets">Support 
    hot code replace when debugging compliant Java 1.4 targets</a>.</b> 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.&nbsp; 
    Provide smart drop to frame that only removes affected frames from the stack.
  <p><b><a name="Enable JSP debugging with JPDA">Enable JSP debugging

with JPDA</a>.</b> The Java debugger will enable JSP debugging via a flexible source lookup algorithm and breakpoint setting mechanism.

<p><a name="Add debugger support for step filtering"><b>Add debugger

support for step filtering</b></a><b>.</b> The Java debugger will avoid stepping into

any class mentioned on a user-specified exclusion list.

<p><b><a name="Improve data inspectors">Improve data inspectors</a>.</b> 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.

  <p>[<u><font color="#008000">Previously uncommitted item</font></u>] <a name="Add API for Java abstract syntax tree"><b>Add

API for Java abstract syntax tree</b></a><b>.</b> 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.&nbsp;</p>

  <p>[<u><font color="#008000">Previously uncommitted item</font></u>] <b><a name="Add field watchpoints">Support field

  watchpoints</a>.</b> We will add debugger support for field watchpoints.</p>

  <p>[<u><font color="#008000">Previously uncommitted item</font></u>] <a name="Improve Java editor"><b>Support editor key bindings</b></a>. Add support for user-configurable key

  bindings in the Java editor. This requires changes in the Platform UI

  component.<p>[<u><font color="#008000">New item</font></u>] <b><a name="Add support for JUnit">Add
  support for JUnit</a>.</b>  We will include special tooling for the popular <a href="http://www.junit.org/">JUnit
  unit test framework</a> to facilitate authoring and running of JUnit test
  cases.<p>[<u><font color="#008000">New
  item</font></u>] <b><a name="Add support for Javadoc generation">Add support for Javadoc
  generation</a>.</b> We will add an action for generating Javadoc for a Java
  project (note: requires a standard JDK).<p>[<u><font color="#008000">New
  item</font></u>] <b>Improve navigating to Javadoc.</b>
  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.</blockquote>



<h4>

<a name="Uncommitted Items">

Uncommitted Items</a> (Eclipse JDT subproject)</h4>

<p><i>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.</i></p>



<blockquote>
  <p> <a name="Add conditional breakpoints"><b>Support conditional

  breakpoints</b></a><b>.</b> We will add debugger support

  for conditional breakpoints

with simple conditions, including simply object identity tests of the form

  &quot;this == id&quot; sufficient for object breakpoints.</p>

</blockquote>



<p>(End of items for Eclipse JDT subproject.)



<h3>

<a name="Plug-in development environment (PDE) subproject">Plug-in development environment (PDE) subproject</a></h3>

The <a href="http://www.eclipse.org/pde/index.html"> plug-in development environment</a> 
(PDE) consists of&nbsp;tools for developing plug-ins for the Eclipse Platform. 
For 2.0, the goal is to maintain the level of PDE support present in 1.0 while 
adding the necessary extensions that allow it to be the tool of choice for self-hosted 
Eclipse Project development. The following items are committed for 2.0: 
<blockquote> <b><a name="Improve accessibility - PDE">Improve accessibility</a>.</b> 

  Applications selling to the US Government market are required by law to meet 

  minimum accessibility guidelines (<a href="http://www.section508.gov/" target="_top">Section 

  508</a>). The PDE UI must meet minimum accessibility guidelines, and enable 

  its client plug-ins to meet accessibility guidelines as well. 

  <p><b><a name="Support revamped install and update story">Support

  revamped install and update story</a>.</b> 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.</p>

  <p><b><a name="Improve support for large scale multi-project plug-in development">Improve

  support for large scale multi-project plug-in development</a>.</b> We will improve support

  for large scale development efforts involving multiple plug-ins spread across

  several projects in the workspace.</p>

  <p>[<u><font color="#008000">New item</font></u>] <b><a name="Provide PDE API">Provide
  PDE API</a>.</b>  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.&nbsp;<p>[<u><font color="#008000">New item</font></u>]
  <b><a name="Source builds">Source builds</a>.</b>  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.

</blockquote>



<p>(End of items for Eclipse PDE subproject.)

</body>

</html>