development/eclipse_project_plan_2_1_20020830.html - www.eclipse.org/eclipse - Git at Google

 <!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 Draft 2.1 Plan (Draft of Aug. 30, 2002)</title>

    <link rel="stylesheet" href="../../default_style.css" type="text/css">

 </head>

 <body>


 <h1>

 Eclipse Project<br>

 DRAFT 2.1 Plan</h1>

 <p>Last revised Friday, August 30, 2002<br>
 <br>
 <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 feature and API set for the next feature release
   of Eclipse, designated release 2.1.
 <p>Plans do not materialize out of nowhere, nor are they entirely static. To make
   the planning process more transparent and open to the Eclipse community, we
   (the Eclipse PMC) are posting the plan in an embryonic form and are revising
   it throughout the release cycle.&nbsp;
 <p>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.&nbsp;<p>The remainder of the plan consists of plan items for the various
 Eclipse subprojects. Each plan item covers a feature or API that is to be added
 to Eclipse, or some aspect of Eclipse that is to be improved. Each plan item has
 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
 details (which can be hashed out elsewhere).&nbsp;
 <p>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 Platform component; others may involve coordinated changes to several
   components; other may pervade the entire Platform.
 <p>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, 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. All interesting
   feature work is accounted for in this plan.
 <p>The current status of each plan item is
 noted:
 <ul>
   <li><b>Proposed</b> plan item - A proposal for an aspect to work on for the
     release. After due consideration, a proposal will either be committed,
     rejected, or deferred.</li>
   <li><b>Committed</b> plan item - A committed plan item is one that we have decided
     to address for the release.</li>
   <li><b>Deferred</b> plan item - A reasonable proposal that did not make it in
     to this release for some reason is marked as deferred with a brief note as
     to why they were deferred. Deferred plan items may resurface as proposed plan
     items at a later point.</li>
   <li><b>Rejected</b> plan item - Plan items that were proposed but judged unworkable
     are marked as rejected plan items, with an accompanying summary of why they
     were dismissed. Keeping track of rejected items avoids repeating the discussion.</li>
 </ul>
 <h2>Release deliverables</h2>

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

 <ul>

   <li>Source code release for Eclipse Project, available as versions tagged &quot;R2_1&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><a name="Milestones"></a>Release milestones</h2>

 <p>Release milestone occurring at roughly monthly intervals exist to facilitate
 coarse-grained planning and staging. The milestones for the remainder of this
 year are:</p>

 <ul>
   <li>September 20, 2002 - Milestone 1 - (2.1 M1) - stable build reflecting progress</li>
   <li>October 18, 2002 - Milestone 2 - (2.1 M2) - stable build reflecting progress</li>
   <li>November 15, 2002 - Milestone 3 - (2.1 M3) - stable build reflecting
     progress</li>
   <li>December 13,&nbsp; 2002 - Milestone 4 - (2.1 M4) - stable build reflecting
     progress</li>
 </ul>

 <p> Additional 2003 milestones will be added later. Our target
 is to complete 2.1 late in 1Q2003. 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>In order to remain current, each Eclipse release targets reasonably current
 versions of the underlying operating environments.</p>

 <p>Most of the Eclipse SDK is &quot;pure&quot; Java code 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 is written
 and compiled 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>Eclipse SDK 2.0 has been tested and validated on the following Java 2
 Platform implementations:</p>
 <table width="91%" border="1">
   <tbody>
     <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>
   </tbody>
 </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:
 &quot;Primary&quot; means a full tested configuration; &quot;</span>Secondary&quot;
 means a configuration which is only lightly tested; &quot;Untested&quot; means a
 configuration that has received no testing, but which should work.</p>
 <table width="91%" border="1">
   <tbody>
     <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;</p>
       </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%">Primary</td>
     </tr>
     <tr>
       <td width="42%">SuSE Linux 7.3 x86 GTK 2.0</td>
       <td width="19%">Primary</td>
     </tr>
     <tr>
       <td width="42%">Other Linux; kernel version 2.4.7, and GTK 2.0</td>
       <td width="19%">Untested</td>
     </tr>
   </tbody>
 </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 are supported by the Eclipse SDK on all of the above
 operating environments; DBCS and BIDI locales are supported by the Eclipse SDK
 only on Windows operating environments.
 <p>The Eclipse SDK supports 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>German and Japanese locales have been tested.
 <h4>BIDI support</h4>
 <p>The Eclipse SDK is a development environment targeted at technical
 professionals - not an end user application. However, the Eclipse SDK 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 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><i>IMPORTANT: The above BIDI support is available only on Windows platforms.</i></p>

 <h2>

 Compatibility with Previous Releases</h2>

 <p>

 It is a given that Eclipse 2.1 will be upwards compatible with Eclipse 2.0. And
 incompatible break with the past this early on would be both unwelcome and
 unwarranted.</p>

 <h3>

 Compatibility of Release 2.1 with 2.0</h3>

 The Eclipse SDK 2.1 will be upwards compatible with the Eclipse SDK 2.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.1 release notes so that
 clients can assess the impact of these changes on their plug-ins and products.

 <p><b>API Contract Compatibility:</b> The Eclipse SDK 2.1 will be upwards contract-compatible
   with the Eclipse SDK 2.0 unless noted. This means that programs in full compliance
   with contracts specified in the Eclipse SDK 2.0 APIs will automatically be in
   full compliance with the Eclipse SDK 2.1 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.1 APIs would ensure compliance with the Eclipse SDK 2.0 APIs.
 <p><b>Binary (plug-in) Compatibility:</b> The Eclipse SDK 2.1 will be upwards
   binary-compatible with the Eclipse SDK 2.0 unless noted. This means that plug-ins
   built for the Eclipse SDK 2.0 will continue to work correctly in the Eclipse
   SDK 2.1 without change. Downward plug-in compatibility is not supported. Plug-ins
   for the Eclipse SDK 2.1 are unlikely to be usable in the Eclipse SDK 2.0. Plug-ins
   with hard-coded references in their plug-in manifest file to 2.0 versions of
   prerequisite Eclipse Project plug-ins will work in 2.1 provided the version match
 rule is &quot;greaterOrEqual&quot;
 or &quot;compatible&quot; (the default); references
 using &quot;perfect&quot; or &quot;equivalent&quot; match rules will be broken.
 <p><b>Source Compatibility:</b> The Eclipse SDK 2.1 will be upwards source-compatible
   with the Eclipse SDK 2.0 unless noted. This means that source files written
   to use the Eclipse SDK 2.0 APIs can be successfully compiled and run against
   the Eclipse SDK 2.1 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.1 will be upwards

 workspace-compatible with Eclipse SDK 2.0 unless noted. This means that

 workspaces and projects created with Eclipse SDK 2.0 can be successfully opened by Eclipse SDK
 2.1 and upgraded to a 2.1 workspace.&nbsp; Individual plug-ins developed for

 Eclipse SDK 2.0 should provide similar upwards compatibility for their workspace

 metadata; plug-in developers are responsible for ensuring that their plug-ins

 recognize 2.0 metadata and process it appropriately. 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.1 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><a href="#Eclipse Platform subproject">Eclipse Platform</a>

 <br><a href="#Java development tooling (JDT) subproject">JDT - Java development tooling</a>

 <br><a href="#Plug-in development environment (PDE) subproject">PDE - Plug-in development environment</a></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 components affected by that work item (many items involve coordinated changes
   to several components).

 <h3>

 <a name="Eclipse Platform subproject">Eclipse Platform subproject</a></h3>

 The Eclipse Platform provides the most fundamental building blocks. The following items reflect new features of the Eclipse Platform, or areas

 where existing features will be significantly reworked.
 <h4>Proposed Items (Eclipse Platform subproject)</h4>
 <blockquote>
 <p><b>Improved Platform startup times</b>.&nbsp; Progress was made to improve
 startup times in 2.0; however, additional improvements are needed. In addition, we need to investigate deferring (or partially omitting) the
 recovery of the UI state. [Platform Core, Platform UI]</p>
 <p><b>User configurable key bindings.</b>&nbsp; Ability for user to redefine the
 key bindings for the editor and the menu accelerators. [Platform UI]</p>
   <p><b>Improve support for cheat sheets</b>.&nbsp; A cheat sheet is an instance
     of a simple kind of workflow support. The Welcome Page editor is a simple
     example of a cheat sheet. We will provide a standard API for creating cheat
     sheets. [Platform UI]</p>
 </blockquote>
 <h4>Committed Items (Eclipse Platform subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>
 <h4>Deferred Items (Eclipse Platform subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>
 <h4>Dismissed Items (Eclipse Platform subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>


 <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 work items reflect new features of JDT, or areas where existing

 features will be significantly reworked.
 <h4>Proposed Items (Eclipse JDT subproject)</h4>
 <blockquote>
 <p><b>Building projects with circular dependencies.</b>&nbsp; Some users are
 experiencing difficulty partitioning their work into
 independently-buildable projects. We want to add a mechanism to allow mutually dependent projects to be
 built
 successfully, while preserving current project build order behavior.</p>
   <p><b>More flexible project layout.&nbsp; </b>Support build output folders that are outside of the
   workspace.</p>
 </blockquote>
 <h4>Committed Items (Eclipse JDT subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>
 <h4>Deferred Items (Eclipse JDT subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>
 <h4>Dismissed Items (Eclipse JDT subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></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.

 The following work items reflect new features of PDE, or areas where existing

 features will be significantly reworked.
 <h4>Proposed Items (Eclipse PDE subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>
 <h4>Committed Items (Eclipse PDE subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>
 <h4>Deferred Items (Eclipse PDE subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>
 <h4>Dismissed Items (Eclipse PDE subproject)</h4>
 <blockquote>
   <p><i>None at this time.</i></p>
 </blockquote>


 <p>(End of items for Eclipse PDE subproject.)

 </body>

 </html>
	<!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 Draft 2.1 Plan (Draft of Aug. 30, 2002)</title>

	<link rel="stylesheet" href="../../default_style.css" type="text/css">

	</head>

	<body>



	<h1>

	Eclipse Project<br>

	DRAFT 2.1 Plan</h1>

	<p>Last revised Friday, August 30, 2002<br>
	<br>
	<i>    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 feature and API set for the next feature release
	of Eclipse, designated release 2.1.
	<p>Plans do not materialize out of nowhere, nor are they entirely static. To make
	the planning process more transparent and open to the Eclipse community, we
	(the Eclipse PMC) are posting the plan in an embryonic form and are revising
	it throughout the release cycle.
	<p>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. <p>The remainder of the plan consists of plan items for the various
	Eclipse subprojects. Each plan item covers a feature or API that is to be added
	to Eclipse, or some aspect of Eclipse that is to be improved. Each plan item has
	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
	details (which can be hashed out elsewhere).
	<p>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 Platform component; others may involve coordinated changes to several
	components; other may pervade the entire Platform.
	<p>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, 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. All interesting
	feature work is accounted for in this plan.
	<p>The current status of each plan item is
	noted:
	<ul>
	<li><b>Proposed</b> plan item - A proposal for an aspect to work on for the
	release. After due consideration, a proposal will either be committed,
	rejected, or deferred.</li>
	<li><b>Committed</b> plan item - A committed plan item is one that we have decided
	to address for the release.</li>
	<li><b>Deferred</b> plan item - A reasonable proposal that did not make it in
	to this release for some reason is marked as deferred with a brief note as
	to why they were deferred. Deferred plan items may resurface as proposed plan
	items at a later point.</li>
	<li><b>Rejected</b> plan item - Plan items that were proposed but judged unworkable
	are marked as rejected plan items, with an accompanying summary of why they
	were dismissed. Keeping track of rejected items avoids repeating the discussion.</li>
	</ul>
	<h2>Release deliverables</h2>

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

	<ul>

	<li>Source code release for Eclipse Project, available as versions tagged "R2_1"
	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><a name="Milestones"></a>Release milestones</h2>

	<p>Release milestone occurring at roughly monthly intervals exist to facilitate
	coarse-grained planning and staging. The milestones for the remainder of this
	year are:</p>

	<ul>
	<li>September 20, 2002 - Milestone 1 - (2.1 M1) - stable build reflecting progress</li>
	<li>October 18, 2002 - Milestone 2 - (2.1 M2) - stable build reflecting progress</li>
	<li>November 15, 2002 - Milestone 3 - (2.1 M3) - stable build reflecting
	progress</li>
	<li>December 13,  2002 - Milestone 4 - (2.1 M4) - stable build reflecting
	progress</li>
	</ul>

	<p> Additional 2003 milestones will be added later. Our target
	is to complete 2.1 late in 1Q2003. 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>In order to remain current, each Eclipse release targets reasonably current
	versions of the underlying operating environments.</p>

	<p>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 2 Platform itself. The 2.0 release of the Eclipse Project is written
	and compiled 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>Eclipse SDK 2.0 has been tested and validated on the following Java 2
	Platform implementations:</p>
	<table width="91%" border="1">
	<tbody>
	<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>
	</tbody>
	</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.</p>
	<table width="91%" border="1">
	<tbody>
	<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">
	<p>Linux on Intel x86</p>
	<p> </p>
	</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 </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%">Primary</td>
	</tr>
	<tr>
	<td width="42%">SuSE Linux 7.3 x86 GTK 2.0</td>
	<td width="19%">Primary</td>
	</tr>
	<tr>
	<td width="42%">Other Linux; kernel version 2.4.7, and GTK 2.0</td>
	<td width="19%">Untested</td>
	</tr>
	</tbody>
	</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 are supported by the Eclipse SDK on all of the above
	operating environments; DBCS and BIDI locales are supported by the Eclipse SDK
	only on Windows operating environments.
	<p>The Eclipse SDK supports 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>German and Japanese locales have been tested.
	<h4>BIDI support</h4>
	<p>The Eclipse SDK is a development environment targeted at technical
	professionals - not an end user application. However, the Eclipse SDK 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 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><i>IMPORTANT: The above BIDI support is available only on Windows platforms.</i></p>

	<h2>

	Compatibility with Previous Releases</h2>

	<p>

	It is a given that Eclipse 2.1 will be upwards compatible with Eclipse 2.0. And
	incompatible break with the past this early on would be both unwelcome and
	unwarranted.</p>

	<h3>

	Compatibility of Release 2.1 with 2.0</h3>

	The Eclipse SDK 2.1 will be upwards compatible with the Eclipse SDK 2.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.1 release notes so that
	clients can assess the impact of these changes on their plug-ins and products.

	<p><b>API Contract Compatibility:</b> The Eclipse SDK 2.1 will be upwards contract-compatible
	with the Eclipse SDK 2.0 unless noted. This means that programs in full compliance
	with contracts specified in the Eclipse SDK 2.0 APIs will automatically be in
	full compliance with the Eclipse SDK 2.1 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.1 APIs would ensure compliance with the Eclipse SDK 2.0 APIs.
	<p><b>Binary (plug-in) Compatibility:</b> The Eclipse SDK 2.1 will be upwards
	binary-compatible with the Eclipse SDK 2.0 unless noted. This means that plug-ins
	built for the Eclipse SDK 2.0 will continue to work correctly in the Eclipse
	SDK 2.1 without change. Downward plug-in compatibility is not supported. Plug-ins
	for the Eclipse SDK 2.1 are unlikely to be usable in the Eclipse SDK 2.0. Plug-ins
	with hard-coded references in their plug-in manifest file to 2.0 versions of
	prerequisite Eclipse Project plug-ins will work in 2.1 provided the version match
	rule is "greaterOrEqual"
	or "compatible" (the default); references
	using "perfect" or "equivalent" match rules will be broken.
	<p><b>Source Compatibility:</b> The Eclipse SDK 2.1 will be upwards source-compatible
	with the Eclipse SDK 2.0 unless noted. This means that source files written
	to use the Eclipse SDK 2.0 APIs can be successfully compiled and run against
	the Eclipse SDK 2.1 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.1 will be upwards

	workspace-compatible with Eclipse SDK 2.0 unless noted. This means that

	workspaces and projects created with Eclipse SDK 2.0 can be successfully opened by Eclipse SDK
	2.1 and upgraded to a 2.1 workspace.  Individual plug-ins developed for

	Eclipse SDK 2.0 should provide similar upwards compatibility for their workspace

	metadata; plug-in developers are responsible for ensuring that their plug-ins

	recognize 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 Eclipse SDK 2.1 will be unusable with an earlier version

	of Eclipse SDK.

	<p><b>Non-compliant usage of API's</b>: 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 <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><a href="#Eclipse Platform subproject">Eclipse Platform</a>

	<br><a href="#Java development tooling (JDT) subproject">JDT - Java development tooling</a>

	<br><a href="#Plug-in development environment (PDE) subproject">PDE - Plug-in development environment</a></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 components affected by that work item (many items involve coordinated changes
	to several components).

	<h3>

	<a name="Eclipse Platform subproject">Eclipse Platform subproject</a></h3>

	The Eclipse Platform provides the most fundamental building blocks. The following items reflect new features of the Eclipse Platform, or areas

	where existing features will be significantly reworked.
	<h4>Proposed Items (Eclipse Platform subproject)</h4>
	<blockquote>
	<p><b>Improved Platform startup times</b>.  Progress was made to improve
	startup times in 2.0; however, additional improvements are needed. In addition, we need to investigate deferring (or partially omitting) the
	recovery of the UI state. [Platform Core, Platform UI]</p>
	<p><b>User configurable key bindings.</b>  Ability for user to redefine the
	key bindings for the editor and the menu accelerators. [Platform UI]</p>
	<p><b>Improve support for cheat sheets</b>.  A cheat sheet is an instance
	of a simple kind of workflow support. The Welcome Page editor is a simple
	example of a cheat sheet. We will provide a standard API for creating cheat
	sheets. [Platform UI]</p>
	</blockquote>
	<h4>Committed Items (Eclipse Platform subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>
	<h4>Deferred Items (Eclipse Platform subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>
	<h4>Dismissed Items (Eclipse Platform subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>



	<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 work items reflect new features of JDT, or areas where existing

	features will be significantly reworked.
	<h4>Proposed Items (Eclipse JDT subproject)</h4>
	<blockquote>
	<p><b>Building projects with circular dependencies.</b>  Some users are
	experiencing difficulty partitioning their work into
	independently-buildable projects. We want to add a mechanism to allow mutually dependent projects to be
	built
	successfully, while preserving current project build order behavior.</p>
	<p><b>More flexible project layout.  </b>Support build output folders that are outside of the
	workspace.</p>
	</blockquote>
	<h4>Committed Items (Eclipse JDT subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>
	<h4>Deferred Items (Eclipse JDT subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>
	<h4>Dismissed Items (Eclipse JDT subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></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 tools for developing plug-ins for the Eclipse Platform.

	The following work items reflect new features of PDE, or areas where existing

	features will be significantly reworked.
	<h4>Proposed Items (Eclipse PDE subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>
	<h4>Committed Items (Eclipse PDE subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>
	<h4>Deferred Items (Eclipse PDE subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>
	<h4>Dismissed Items (Eclipse PDE subproject)</h4>
	<blockquote>
	<p><i>None at this time.</i></p>
	</blockquote>



	<p>(End of items for Eclipse PDE subproject.)

	</body>

	</html>