Google Git
Sign in
eclipse / gerrit / www.eclipse.org / eclipse / cfe0449a33f0ce9f45c2dd97fe2ca61f777578e2 / . / eclipse_project_plan_2_0_rev1221.html
blob: f7a7fa62032a52cfa46b4839afbf72457ed4e3b4 [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 Friday, December 21, 2001
<blockquote>
<p><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>
</blockquote>
<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 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 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 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 <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 Eclipse <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.
<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 <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 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 - feature complete -
initial development&nbsp; freeze</li>
</ul>
The 2.0 release is targeted for April 2002. 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.
<h2>
Target Operating Environments</h2>
<p>Most of Eclipse 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 Eclipse 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 (currently in beta)</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
(currently in beta)</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 (currently in beta)</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
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</td>
<td width="19%"><i>Early access</i></td>
</tr>
<tr>
<td width="42%">
SuSE Linux 7.3 x86</td>
<td width="19%"><i>Early access</i></td>
</tr>
<tr>
<td width="42%">Other Linux; kernel version 2.4.7, and GTK version 1.2.8,
1.2.9, or 1.2.10</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 components, including
dialogs and error messages, are externalized. The English strings are provided
as the default resource bundles.</p>
<p>We will perform basic tests in German and Japanese locales.
<p>IMPORTANT: Internationalization is supported only on Windows platforms in the
2.0 release.&nbsp; (See the <a href="#Uncommitted Items">Eclipse Platform
uncommitted items</a> for additional work in this area.)
<h4>
BIDI support</h4>
<p> Eclipse is a platform for building development environments targeted at technical
professionals. Eclipse 2.0 will permit technical professionals who are working
in English to build Hebrew/Arabic end-user applications.</p>
<p>IMPORTANT: BIDI is supported only on Windows platforms in the 2.0 release.</p>
<h2>
Compatibility with Previous Release</h2>
Eclipse 2.0 will be upwards compatible with Eclipse 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 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 (with the exception of Scripting). 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> Eclipse 2.0 will be upwards
contract-compatible with Eclipse 1.0 unless noted. This means that
programs in full compliance with contracts specified in the Eclipse 1.0
APIs will automatically be in full compliance with the Eclipse 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 2.0 APIs would ensure compliance with
the Eclipse 1.0 APIs.
<p><b>Binary (plug-in) Compatibility:</b> Eclipse 2.0 will be upwards
binary-compatible
with Eclipse 1.0 unless noted. This means that plug-ins built for Eclipse
1.0 will continue to work correctly in Eclipse 2.0 without change. Downward
plug-in compatibility is not supported. Plug-ins for Eclipse
2.0 are unlikely to be usable in Eclipse 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> Eclipse 2.0 will be upwards source-compatible
with Eclipse 1.0 unless noted. This means that source files written
to use Eclipse 1.0 APIs can be successfully compiled and run against the
Eclipse 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 APIs, they will not be usable with an earlier version of Eclipse.
<p><b>Workspace Compatibility:</b> Eclipse 2.0 will be upwards
workspace-compatible with Eclipse 1.0 unless noted. This means that
workspaces and projects created with Eclipse 1.0 can be successfully opened by Eclipse
2.0 and upgraded to a 2.0 workspace.&nbsp; Individual plug-ins developed for
Eclipse 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 1.0 plug-ins (ones with provisional APIs) are unlikely to automatically
upgrade their metadata to 2.0. Downward workspace compatibility is not supported. A workspace created
(or opened) by Eclipse 2.0 will be unusable with an earlier version
of Eclipse.&nbsp;&nbsp;
<p><b>Non-compliant usage of Eclipse</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 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 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. A likely improvement in startup
time will come with computing and caching the plug-in registry on disk.
<p><a name="Improve Ant integration"><b>Provide first-class Ant integration</b></a><b>.</b>
In 1.0, Ant was a second-class Eclipse citizen. We plan to significantly increase the Platform's
power and flexibility by connecting it to the Platform's build story. These changes will likely impact the UI component
as well.
<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.</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 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 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 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 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.</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 Eclipse. 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><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. We believe that Eclipse itself
requires no specific changes to support GB 18030, but is entirely dependent on
the Java 2 Runtime Environment to provide the necessary locale and character
encoding support. The GB18030 character encoding is not supported in version
1.3 of Java 2 Platform, but is included in version 1.4.<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.
</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
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 UI.
<p><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 Eclipse 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).</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>Add non-versioning WebDAV repository support.</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><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&nbsp;<br>
present all documentation and online help. This will allow help to be presented in a non-modal way.<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 environment.
<p><b><a name="Allow remote help content">Enable help server</a>s.</b> We will support configurations where help can be served up to an Eclipse client by a remote web&nbsp;<br>
server (the server must support servlets).
<p><b><a name="Support standalone help">Support standalone help</a>.</b> Developers will be able to reuse the Eclipse help function even in products that are not built using the Eclipse technology. We will provide for both in-process and command-line invocation of this support.
<p><b><a name="&quot;Info Center&quot; support">"Info Center" support</a>.</b> It is often desirable to be able to provide plug-in documentation that is accessible to users that do not have Eclipse installed. We will support configurations where online documentation can be hosted on a web server
and viewed through a regular web browser.
</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 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>
<a name="Uncommitted Items">
Uncommitted Items</a> (Eclipse Platform subproject)</h4>
<p><i>N.B. The following is the list of important Eclipse 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 usability of project natures"><b>Improve
usability of project natures</b></a><b>.</b> In Eclipse 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 review and revise
the approach to how project natures are used, presented, and manipulated. These
changes will affect the UI and Core components.
<p><a name="Improve consistency of saving workbench state"><b>Improve
consistency of saving workbench state</b></a><b>.</b> In Eclipse 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><a name="Improve undo/redo in workbench"><b>Improve
undo/redo in workbench</b></a><b>.</b> In Eclipse 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. These changes will affect the UI
component.
<p><a name="Provide a standard Console view"><b>Provide
a standard Console view</b></a><b>.</b> In Eclipse 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><a name="Improve support for cheat sheets"><b>Improve
support for cheat sheets</b></a><b>.</b> In Eclipse 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.<p><b><a name="Allow pre-validation of rename/move/delete">Allow pre-validation of
rename/move/delete</a>.</b> VCM providers that
need to manage a project's namespace would like advance notification of
impending resource moves, renames, and deletes. (Other clients would like a
similar opportunity to veto inappropriate name changes to their resources;
this is a different concern.) We will add a callback so that the
relevant VCM provider will be able to register for advance notification with
an opportunity to veto. These changes will affect the UI and Core components.
<p><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. There needs to be some means of dealing with this;
depending on the solution, this may require support from Core and UI.</p>
<p><a name="Add search support"><b>Add help search support</b></a><b>.</b>
We will provide the ability to search help documentation. This change will
affect the Help component.<p><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 Eclipse 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.<p><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.
</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 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><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; navigate to a method's super
implementation; add bracket matching.
<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><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 add another
presentation that shows packages independent of their physical containment. 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><b><a name="Allow runtime classpath to the configured">Allow runtime
classpath to the configured</a>.</b> Using the new launch configuration mechanism
provided by the Platform Debug component will allow the runtime classpath,
boot classpath, extension directories, and other VM-type specific launch
parameters to be configured.
<p><b><a name="Support hot code replace when debugging JDK 1.4 targets">Support hot code replace when
debugging compliant JDK 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.<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.</blockquote>
<h4>
Uncommitted Items</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 API for Java abstract syntax tree"><b>Add
API for Java abstract syntax tree</b></a><b>.</b> In Eclipse 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><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>
<p><b><a name="Add field watchpoints">Support field
watchpoints</a>.</b> We will add debugger support for field watchpoints.</p>
<p><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.
</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; Eclipse-based tools
for developing Eclipse plug-ins. 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>
</blockquote>
</body>
</html>