Google Git
Sign in
eclipse / www.eclipse.org / eclipse / 283e5aa56519b7305d9800532d37435bbb478daf / . / eclipse_project_plan_2_0_rev0214.html
blob: 842083b76704761080edb1bf07f295afedd771ec [file] [log] [blame]
<!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>