Google Git
Sign in
eclipse / www.eclipse.org / eclipse / 55f51e59ba8cbe95e3ecfd429c782920bef82a61 / . / development / eclipse_project_plan_3_0_20030522.html
blob: fda9c95dce28e4d55ef3b9984759844096266e62 [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 Draft 3.0 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>
<h1>
Eclipse Project<br>
DRAFT 3.0 Plan</h1>
<p>Last revised Thursday May 22, 2003 (replaces the <a href="http://eclipse.org/eclipse/development/eclipse_project_plan_2_2_20021220.html">draft
2.2 plan of Dec. 20, 2002</a>; <img border="0" src="new.gif" width="12" height="12">
marks interesting changes since the <a href="http://eclipse.org/eclipse/development/eclipse_project_plan_2_1.html">final
2.1 plan</a>)<br>
<br>
<i>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to the </i><a href="mailto:eclipse-dev@eclipse.org">eclipse-dev@eclipse.org</a>
<i>developer mailing list.</i> </p>
<p>This document lays out the feature and API set for the next feature release
of Eclipse after 2.1, designated release 3.0 (<a href="why_eclipse_3_0.html">Why
Eclipse &quot;3.0&quot;?</a>).
<ul>
<li><a href="#Deliverables">Release deliverables</a></li>
<li><a href="#Milestones">Release milestones</a></li>
<li><a href="#TargetOperatingEnvironments">Target operating environments</a></li>
<li><a href="#Compatibility">Compatibility with previous releases</a></li>
<li><a href="#Platform">Eclipse Platform subproject</a></li>
<li><a href="#JDT">Java development tools (JDT) subproject</a></li>
<li><a href="#PDE">Plug-in development environment (PDE) subproject</a></li>
</ul>
<p>Plans do not materialize out of nowhere, nor are they entirely static. To ensure
the planning process is transparent and open to the entire Eclipse community,
we (the Eclipse PMC) post plans in an embryonic form and revise them throughout
the release cycle.
<p>The first part of the plan
deals with the important matters of release deliverables, release milestones,
target operating environments, and release-to-release compatibility. These are
all things that need to be clear for any release, even if no features were to
change.&nbsp;
<p>The remainder of the plan consists of plan items for the various Eclipse subprojects.
Each plan item covers a feature or API that is to be added to Eclipse, or some
aspect of Eclipse that is to be improved. Each plan item has its own entry in
the Eclipse bugzilla database, with a title and a concise summary (usually a
single paragraph) that explains the work item at a suitably high enough level
so that everyone can readily understand what the work item is without having
to understand the nitty-gritty detail.
<p>Not all plan items represent the same amount of work; some may be quite large,
others, quite small. Some plan items may involve work that is localized to a
single Platform component; others may involve coordinated changes to several
components; other may pervade the entire Platform. Although some plan items
are for work that is more pressing that others, the plan items appear in no
particular order.
<p>With the previous release as the starting point, this is the plan for how we
will enhance and improve it. Fixing bugs, improving test coverage, documentation,
examples, performance, usability, etc. are considered routine ongoing maintenance activities and are
not included in this plan unless they would also involve a significant change
to the API or feature set, or involve a significant amount of work. All interesting
feature work is accounted for in this plan.
<p>The current status of each plan item is
noted:
<ul>
<li><b>Committed</b> plan item - A committed plan item is one that we have decided
to address for the release.</li>
<li><b>Proposed</b> plan item - A proposed plan item is one that we are considering
addressing for the release. Although we are actively investigating it, we
are not yet in a position to commit to it, or to say that we won't be able
to address it. After due consideration, a proposal will either be committed,
deferred, or rejected.</li>
<li><b>Deferred</b> plan item - A reasonable proposal that will not make it
in to this release for some reason is marked as deferred with a brief note
as to why it was deferred. Deferred plan items may resurface as committed
plan items at a later point.</li>
<li><b>Rejected</b> plan item - Plan items that were proposed but judged unworkable
are marked as rejected plan items, with an accompanying summary of why they
were dismissed. Keeping track of rejected items avoids repeating the discussion.</li>
</ul>
<h2><a name="Deliverables"></a>Release deliverables</h2>
<p>The release deliverables have the same form as previous releases, namely:
<ul>
<li>Source code release for Eclipse Project, available as versions tagged &quot;R3_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>
<li>SWT distribution (downloadable).</li>
</ul>
<h2><a name="Milestones"></a>Release milestones</h2>
<p>Release milestone occurring at roughly 6 week intervals exist to facilitate
coarse-grained planning and staging. The milestones for 2003 are:</p>
<ul>
<li>Friday June 6, 2003 - Milestone 1 (3.0 M1) - stable build reflecting progress</li>
<li>Friday July 18, 2003 - Milestone 2 (3.0 M2) - stable build reflecting progress</li>
<li>Friday August 29, 2003 - Milestone 3 (3.0 M3) - stable build reflecting
progress</li>
<li>Friday October 10, 2003 - Milestone 4 (3.0 M4) - initial API freeze - stable
build reflecting progress</li>
<li>Friday November 21, 2003 - Milestone 5 (3.0 M5) - APIs frozen - stable build
reflecting progress</li>
</ul>
<p> Additional 2004 milestones will be added later. Our target is to complete
3.0 in 2Q2004. 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><a name="TargetOperatingEnvironments"></a>Target Operating Environments</h2>
<p>In order to remain current, each Eclipse release targets reasonably current
versions of the underlying operating environments.</p>
<p>Most of the Eclipse SDK is &quot;pure&quot; Java™ code and has no direct dependence
on the underlying operating system. The chief dependence is therefore on the
Java 2 Platform itself. <img border="0" src="new.gif" width="12" height="12">
The 3.0 release of the Eclipse Project is written and compiled against version
1.4 of the Java 2 Platform APIs, and targeted to run on version 1.4 of the Java
2 Runtime Environment, Standard Edition.</p>
<p><img border="0" src="new.gif" width="12" height="12"> There are many different
implementations of the Java 2 Platform running atop a variety of operating systems.
We focus Eclipse testing on a handful of popular <span class="header">combinations
of operating system and Java 2 Platform; these are our <em>reference platforms</em>.
Eclipse undoubtedly runs fine in many operating environments beyond the reference
platforms we test. However, since we do not systematically test them we cannot
vouch for them. Problems encountered when running Eclipse on non-reference platform
that cannot be recreated on any reference platform will be given lower priority
than problems with running Eclipse on a reference platform.</span></p>
<p>Eclipse SDK 3.0 is tested and validated on the following reference platforms
(this list is updated over the course of the release cycle):</p>
<table width="95%" border="1">
<tr>
<td width="20%"><b>Operating system</b></td>
<td width="8%"><b>Processor architecture</b></td>
<td width="6%"><b>Window system</b></td>
<td width="66%"><b>Java 2 Platform</b></td>
</tr>
<tr>
<td>Microsoft Windows XP</td>
<td>Intel x86</td>
<td>Win32</td>
<td>Sun Java 2 SDK, Standard Edition, version 1.4.1_02 for Microsoft Windows</td>
</tr>
<tr>
<td>Microsoft Windows XP</td>
<td>Intel x86</td>
<td>Win32</td>
<td>IBM 32-bit SDK for Windows, Java 2 Technology Edition, version 1.4.0</td>
</tr>
<tr>
<td>RedHat Linux 9 Professional</td>
<td>Intel x86</td>
<td>GTK</td>
<td>Sun Java 2 SDK, Standard Edition, 1.4.1_02 for Linux x86</td>
</tr>
<tr>
<td>RedHat Linux 9 Professional</td>
<td>Intel x86</td>
<td>GTK</td>
<td>IBM Developer Kit for Linux, Java 2 Technology Edition, version 1.4.0</td>
</tr>
<tr>
<td>SuSE Linux 8.2</td>
<td>Intel x86</td>
<td>GTK</td>
<td>Sun Java 2 SDK, Standard Edition, 1.4.1_02 for Linux x86</td>
</tr>
<tr>
<td>SuSE Linux 8.2</td>
<td>Intel x86</td>
<td>GTK</td>
<td>IBM Developer Kit for Linux, Java 2 Technology Edition, version 1.4.0</td>
</tr>
<tr>
<td>Sun Solaris 8</td>
<td>SPARC</td>
<td>Motif</td>
<td>Sun Java 2 SDK, Standard Edition, 1.4.1_02 for Solaris SPARC</td>
</tr>
<tr>
<td>HP HP-UX 11i</td>
<td>hp9000<br>
PA-RISC</td>
<td>Motif</td>
<td><span class="header">HP-UX SDK for the Java 2 platform, version 1.4.1.01
for hp9000 PA-RISC</span></td>
</tr>
<tr>
<td>IBM AIX 5.1</td>
<td>PowerPC</td>
<td>Motif</td>
<td>IBM Developer Kit for AIX, Java 2 Technology Edition, version 1.4</td>
</tr>
<tr>
<td>Apple Mac OS X 10.2</td>
<td>PowerPC</td>
<td>Carbon</td>
<td>Java 2 Standard Edition 1.4.1 for Mac OS X</td>
</tr>
<tr>
<td>QNX Neutrino RTOS <i>[version TDB]</i></td>
<td>Intel x86</td>
<td>Photon</td>
<td>IBM J9 VM for QNX <i>[version TDB]</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 are supported by the Eclipse SDK on all of the above
operating environments; DBCS locales are supported by the Eclipse SDK on the
Windows, GTK, and Motif window systems; BIDI locales are supported by the
Eclipse SDK only on Windows operating environments.
<p>The Eclipse SDK supports GB 18030, the new Chinese code page standard, on Windows
XP and 2000, and Linux.
<p>German and Japanese locales are tested.</p>
<h4>BIDI support</h4>
<p>The Eclipse SDK is a development environment targeted at technical professionals
- not an end user application. However, the Eclipse SDK tools will permit technical
professionals who are working in English to build Hebrew/Arabic end user Java
programs which are themselves not based on the Eclipse SDK. The BIDI support
in the Eclipse SDK allows a Java programmer to work with BIDI strings, code
comments, etc. but the Eclipse SDK itself is not designed to be localized for
BIDI locales and its widget orientation can not be changed.</p>
<p><i>IMPORTANT: The above BIDI support is available only on Windows platforms.</i></p>
<h2><a name="Compatibility"></a>Compatibility with Previous Releases</h2>
<p> <img border="0" src="new.gif" width="12" height="12"> Eclipse 3.0 will not
be fully compatible with Eclipse 2.0 and 2.1.</p>
<h3> Compatibility of Release 3.0 with 2.0 and 2.1</h3>
<p>We have decided that the next release of Eclipse will not be fully compatible
with 2.0 and 2.1. This gives us additional freedom to innovate and make the
next Eclipse significantly better than it could have been had we tried to maintain
compatibility. That said, most of the Eclipse APIs will be the same in 3.0 as
in 2.1. We will only break APIs in 3.0 when have a compelling case for doing
so. And when we find we need to break APIs, we would do it in a controlled way
that minimizes the effort required to port an existing plug-in to the 3.0 APIs.
We will provide a comprehensive <i>Eclipse 3.0 Porting Guide</i> that covers
all areas of breaking API changes, and describes how to port existing 2.1 plug-ins
to 3.0. Up-to-date drafts of the <i>Eclipse 3.0 Porting Guide</i> will be included
with milestone builds so that it's possible to climb aboard the 3.0 release
wagon at the early stages, or to estimate the amount of effort that will be
involved in eventually porting existing plug-ins to 3.0.</p>
<p><b>API Contract Compatibility:</b> Eclipse SDK 3.0 will be upwards contract-compatible
with Eclipse SDK 2.0 and 2.1 except in those areas noted in the <em>Eclipse
3.0 Porting Guide</em>. This means that programs in full compliance with contracts
specified in Eclipse SDK 2.0 or 2.1 APIs will need to be ported to Eclipse SDK
3.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 Eclipse SDK 3.0 APIs would ensure compliance with Eclipse
SDK 2.0 or 2.1 APIs. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain
contract compatibility.
<p><b>Binary (plug-in) Compatibility:</b> Eclipse SDK 3.0 will not be upwards
binary-compatible with Eclipse SDK 2.0 and 2.1. Plug-ins built for Eclipse SDK
2.0 or 2.1 will need to be ported and recompiled for Eclipse SDK 3.0. Downward
plug-in compatibility is not supported either. Plug-ins for Eclipse SDK 3.0
will not be usable in Eclipse SDK 2.0 or 2.1. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain
binary compatibility.
<p><b>Source Compatibility:</b> Eclipse SDK 3.0 will be upwards source-compatible
with Eclipse SDK 2.0 or 2.1 except in the areas noted in the <em>Eclipse 3.0
Porting Guide</em>. This means that source files written to use Eclipse SDK
2.0 or 2.1 APIs might successfully compile and run against Eclipse SDK 3.0 APIs,
although this is not guaranteed. 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 3.0 will be upwards workspace-compatible
with Eclipse SDK 2.0 or 2.1 unless noted. This means that workspaces and projects
created with Eclipse SDK 2.0 or 2.1 can be successfully opened by Eclipse SDK
3.0 and upgraded to a 3.0 workspace. This includes both hidden metadata, which
is localized to a particular workspace, as well as metadata files found within
a workspace project (e.g., the .project file), which may propagate between workspaces
via file copying or team repositories. Individual plug-ins developed for Eclipse
SDK 3.0 should provide similar upwards compatibility for their hidden and visible
workspace metadata created by earlier versions; 3.0 plug-in developers are responsible
for ensuring that their plug-ins recognize 3.0, 2.1, and 2.0 metadata and process
it appropriately. User interface session state may be discarded when a workspace
is upgraded. Downward workspace compatibility is not supported. A workspace
created (or opened) by Eclipse SDK 3.0 will be unusable with an earlier version
of Eclipse SDK.&nbsp;Visible metadata files created (or overwritten) by Eclipse
SDK 3.0 will generally be unusable with earlier versions of Eclipse SDK.
<p><b>Non-compliant usage of API's</b>: All non-API methods and classes, and certainly
everything in a package with &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 releases. 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:
<ul>
<li><a href="#Platform">Eclipse Platform subproject</a></li>
<li><a href="#JDT">Java development tools (JDT) subproject</a></li>
<li><a href="#PDE">Plug-in development environment (PDE) subproject</a></li>
</ul>
<p>For each subproject, the items listed reflect new features of the Eclipse Platform,
or areas where existing features will be significantly reworked. Each item indicates
the components likely affected by that work item (many items involve coordinated
changes to several components). Numbers in parentheses link to bugzilla problem
reports for that plan item (<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=JDT&product=PDE&product=Platform&keywords=plan&target_milestone=3.0&target_milestone=3.0+M1&target_milestone=3.0+M2&target_milestone=3.0+M3&target_milestone=3.0+M4&target_milestone=3.0+M5">query
bugzilla for all 3.0 plan items</a>).
<h2> <a name="Platform">Eclipse Platform subproject</a></h2>
<p>The Eclipse Platform provides the most fundamental building blocks. Plan items
reflect new features of the Eclipse Platform, or areas where existing features
will be significantly reworked. Many of the changes under consideration for
the next release of the Eclipse Platform address three major themes. Since each
theme has a number of items, the committed, proposed, and deferred plan items
are grouped in sections by theme:</p>
<ul>
<li><a href="#ThemeUserExperience">User experience theme</a> - Improving Eclipse
from the point of view of the end user.</li>
<li><a href="#ThemeResponsiveUI">Responsive UI theme</a> - Making it easier
to write Eclipse plug-ins that keep the UI responsive.</li>
<li><a href="#ThemeRCP">Rich client platform theme</a> - Generalizing Eclipse
into a platform for building non-IDE applications.</li>
</ul>
<p>In addition, there are important Eclipse Platform improvements that do not
naturally fit into any of the above themes.</p>
<ul>
<li><a href="#OtherPlatform">Other Eclipse Platform items</a></li>
</ul>
<h3><a name="ThemeUserExperience">Theme: User Experience</a></h3>
<p>Improving Eclipse from the point of view of the end user. This includes improving
both the &quot;out of the box&quot; experience so that new users are productive
faster, and finding better ways to scale up to large numbers of plug-ins without
overwhelming the user.</p>
<h4>Committed Items (Eclipse Platform subproject, User Experience theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve UI
scalability.</b> Despite efforts to ensure UI scalability with a large base
of available tools, the Eclipse workbench still intimidates many users with
long menus, wide toolbars, and lengthy flat lists of preferences. This problem
is acute in large Eclipse-based products. The Platform should provide additional
ways for controlling workbench clutter, such as further menu and toolbar customizability,
distinguishing between novice and advanced functions, supporting different
developer roles, and more specific object contributions for particular file
types. [Platform UI, Platform Debug, JDT UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37929">37929</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve initial
user experience.</b> Users who are new to an Eclipse-based product can find
their first experiences with it overwhelming, even daunting. The initial experience
would be improved if a product could preconfigure the workbench to show only
the subset of function that a new user really needs; welcome pages could be
personalized for particular users roles or levels of experience. [Platform
UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37664">37664</a>)</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <b>Aid ongoing
learning.</b> Users who work with a complex Eclipse-based product need not
be familiar with all of its function in order to be productive. When they
do come to use function which they have never used before (or not recently
enough to be fresh in memory), it is important that the product be able to
quickly train and guide the user in using that new function. The current Eclipse
has many elements that aid learning (examples, tips and tricks, F1 help, active
help links); the work item is to apply them effectively in the Eclipse UI
and recommend how other plug-ins do similarly. [Platform UI, Help] [Theme:
User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37666">37666</a>)</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve UI
affordances.</b> There are a number of areas of the UI where Eclipse is not
providing enough cues to the user (e.g., no cue for available help, no cue
for maximize/restore view, no cue for mandatory/optional fields in wizards).
Make a systematic pass though the UI to improve its affordances. [Platform
UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37667">37667</a>)</p>
<p>(2.1 deferred item) <b>Improve file encoding support.</b> Eclipse 2.1 uses
a single global file encoding setting for reading and writing files in the
workspace. This is problematic; for example, when Java source files in the
workspace use OS default file encoding while XML files in the workspace use
UTF-8 file encoding. The Platform should support non-uniform file encodings.
[Platform Core, Platform UI, Text, Search, Compare, JDT UI, JDT Core] [Theme:
User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37933">37933</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Evolve the
Eclipse user experience.</b> Eclipse 3.0 should have a new look that makes
more effective use of the capabilities of current desktop computers. This
includes allowing the user to customize the workbench by creating floating
toolbars and views, and supporting tear-off views and dockable toolbars where
supported by the underlying window system. [Platform UI, JDT UI, SWT] [Theme:
User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37997">37997</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
keyboard bindings. </strong>Several things should be done to improve keyboard
bindings. First, custom key bindings currently work only in the main Eclipse
window, and not in secondary windows like dialogs, wizards, and floating views
(another plan item). For example, custom editor key bindings do not work in
a text control in a preference dialog. Eclipse should support custom key bindings
in the places where the user reasonably expects. Second, the key customization
dialog should be improved. Finally, make a systematic pass through the UI
to rationalize the initial set of key bindings. [Platform UI, SWT] [Theme:
User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37934">37934</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
editor management.</strong> The current mechanism for switching between editors
using tabs does not scale to having many open editors. Eclipse should provide
a more scalable and stable, yet efficient, UI for switching between editors.
[Platform UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37670">37670</a>)</p>
</blockquote>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
text editor interaction. </strong>The text editor should support folding of
text regions, which can be leveraged by the Java editor to collapse regions,
such as an individual method's body or Javadoc comment, or the import declarations
of a compilation unit. The text editor should also support splitting so that
the user can simultaneously view and edit discontiguous regions of the same
document. [Platform Text, JDT UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37671">37671</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new)<strong> Improve
text editor presentation.</strong> The text editor should support an optional
marginal change bar that can show how the current document differs from another
of its states, such as a local history state or a repository version. Also,
text editors should support for emphasizing a text region by changing its
background color. [Platform Text, JDT UI] [Theme: User Experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37672">37672</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
text editor typing.</strong> The set of key actions available in the text
editor should be enriched with additional common operations like insert line,
duplicate line, transpose, and convert to uppercase. The current JDT editor
support for templates with variables should be generalized and pushed down
so that it is available in all text editors. [Platform Text, JDT UI] [Theme:
User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37674">37674</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
global text search/replace.</strong> Global text search should allow regular
expressions in search patterns. The replace action should be more visible
in the UI, and be easier to use in the case of bulk changes. [Platform Search]
[Theme: User Experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37675">37675</a>)</p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject, User Experience theme)</h4>
<p>The following work items are being actively investigated, but we are not yet
able to promise any solution for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> expanded 2.1 deferred
item) <b>Allow editors to open files outside workspace.</b> A common request
is to be able to use Eclipse to open a file that is not part of the workspace,
or perhaps even one on a remote system. In addition, applications would like
to provide file extension associations so that double-clicking on a file in
the OS desktop would open the associated Eclipse editor. The operations and
capabilities available on these &quot;outside of the workspace&quot; files
would need to be defined. [Platform UI] [Themes: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37935">37935</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Display HTML
in a widget.</b> In Eclipse 2.0 and 2.1, the only supported option for rendering
HTML in the workbench is to use OLE to link to IE. This support is Windows
only; there is no such option in other operating environments. Even on Windows,
this only works for IE and not other browsers. There are already several Eclipse
components that could benefit from HTML display functionality in a widget:
welcome pages; update manager update site overview; hovers that show Javadoc.
The Platform should provide a portable way to display HTML in a widget and
support it in all operating environments. [Platform UI, SWT] [Themes: User
experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36952">36952</a>)</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve workspace
synchronization with file system.</b> A file resource in the workspace gets
out of sync when the underlying file in the file system is created, deleted,
or rewritten outside of Eclipse. File resources usually remains out of sync
until the user explicitly hits Refresh. The Eclipse Platform should provide
ways to keep the in-memory representation in sync with the file system; for
example, by hooking OS file system callbacks where available, and by polling
for file system changes in a background thread. [Platform Core, Platform UI]
[Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36962">36962</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Content-type-based
editor lookup.</strong> The choice of editor is currently based on file name
patterns. This is not very flexible, and breaks down when fundamentally different
types of content are found in files with undistinguished file names or internal
formats. For example, many different models with specialized editors get stored
in XML format files named *.xml. Eclipse should support a notion of content
type for files and resources, and use these to drive decisions like which
editor to use. This feature would also be used by team providers when doing
comparisons based on file type. The several existing file-type registries
in Eclipse should be consolidated. [Platform Core, Platform UI] [Theme: User
experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
support for opening workspaces.</strong> Many users use multiple workspaces
as a way to keep their different projects or work items separate. Currently,
this requires launching Eclipse multiple times with different command line
arguments, which is not particularly convenient for users. Moreover, when
the command line argument is not specified, the workspace location defaults
to a directory inside where the code for Eclipse is installed. Eclipse should
improve how workspaces get opened, use a user-specific default workspace location
more suitable for shared multi-user Eclipse installs, and facilitate switching
between workspaces. [Platform Core, Platform UI] [Themes: User experience]
(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37681">37681</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Provide a
general purpose navigator.</b> The Eclipse Navigator&nbsp;view presents a
view of resources in the workspace. The Eclipse Platform should provide a
more flexible, general purpose, extensible navigator infrastructure that would
make it possible to show other objects as well (like an the extended physical
view provided by Windows Explorer). [Platform UI, JDT UI] [Theme: User experience]
(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36961">36961</a>)</p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, User Experience theme)</h4>
<p>These items are next in line for this release. As committers complete their
assigned tasks, or additional help becomes available, some of these items may
be committed for this release:</p>
<blockquote>
<p>(2.1 deferred item) <b>Add cheat sheets </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36946">36946</a>)<br>
(2.1 deferred item) <b>Add table of contents support to wizards </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36947">36947</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> expanded 2.1 PDE deferred
item) <b>Add project templates </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36960">36960</a>)
<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Allow automation
of common tasks</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37936">37936</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Support workspace
checkpoint and rollback </b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36958">36958</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Allow
dynamic help content </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37676">37676</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Display
HTML help infopops </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37677">37677</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Add capabilities
</b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36959">36959</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Simplify update
manager UI </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37678">37678</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
local history </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37679">37679</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Add Eclipse
automation </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37680">37680</a>)</p>
</blockquote>
<h3><a name="ThemeResponsiveUI">Theme: Responsive UI</a></h3>
<p>Making it easier to write Eclipse plug-ins that keep the UI responsive. Areas
for improvement run the gamut from the UI becoming sluggish (or temporarily
freezing) when blocking operations are done in the UI thread, to long-running
operations like builds and searches which could be performed in the background
while the user continues to work.</p>
<h4>Committed Items (Eclipse Platform subproject, Responsive UI theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Support concurrent
activities.</b> In Eclipse 2.0 and 2.1, certain operations like builds and
searches always run synchronously and block the user at the UI from doing
work until the build has completed. The Eclipse Platform should support operations
running asynchronously in the background, so that the user is not forced to
be entirely idle while long-running operations are in progress. This will
likely require an improved concurrency architecture with more explicit rules.
[Platform UI, Platform Core, Platform Text, JDT Core, JDT UI, PDE] [Theme:
Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36957">36957</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Establish
UI responsiveness targets.</strong> Eclipse should establish quantitative
responsiveness targets for key user actions, such as opening an editor, popping
up a view context menu, switching perspectives, etc. These guidelines should
be supported by automated benchmarks that allow the responsiveness of the
Eclipse UI to be measured and tracked. [Platform, JDT, PDE] [Theme: Responsive
UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37682">37682</a>)</p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject, Responsive UI theme)</h4>
<p>The following work items are being actively investigated, but we are not yet
able to promise any solution for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Address
platform-specific UI performance problems.</strong> There is a noticable UI
performance and responsiveness difference between Eclipse running on Windows
and Eclipse running on Linux GTK, Linux Motif, or QNX Photon, all on the same
hardware, with Windows clearly outperforming the others. Improvements made
to SWT alone have not reduced this &quot;performance gap&quot; enough. In
order to improve Eclipse performance in the other operating environments,
we need to make a concerted effort to determine the root causes (suspects
include low-level thread scheduling and synchronization), and then take steps
to address them. [SWT, Platform UI] [Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37683">37683</a>)</p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, Responsive UI theme)</h4>
<p>These items are next in line for this release. As committers complete their
assigned tasks, or additional help becomes available, some of these items may
be committed for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve update
manager search</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37684">37684</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
scalability for large help books </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37685">37685</a>)</p>
</blockquote>
<h3><a name="ThemeRCP">Theme: Rich client platform</a></h3>
<p>Eclipse was designed as a universal tool integration platform. However, many
facets and components of Eclipse are not particularly specific to IDEs and make
equal sense in non-IDE applications (e.g., window-based GUI, plug-ins, help
system, update manager). Certain changes, like factoring out IDE-specific facilities,
would allow the Eclipse Platform to be generalized into a rich client platform
for building non-IDE applications.</p>
<h4>Committed Items (Eclipse Platform subproject, Rich Client Platform theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b></b> <b>Enable
Eclipse to be used as a rich client platform.</b> Eclipse was designed as
a universal tool integration platform. However, many facets and components
of Eclipse are not particularly specific to IDEs and would make equal sense
in non-IDE applications (e.g., window-based GUI, plug-ins, help system,
update manager). The Eclipse Platform should factor out and segregate IDE-specific
facilities (e.g., everything having to do with workspace resources) so that
a subset of it can be used as a rich client platform for building applications.
[Platform Core, Platform UI, Platform Update] [Theme: Rich client platform]
(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36967">36967</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Provide user
settings.</b> It should be possible to store user settings (preferences, compiler
settings, repositories lists, etc.) that are not specific to a workspace separate
from the workspace, so that they can be used in other workspaces or by other
users. [Platform Core] [Themes: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36965">36965</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Remove
configuration state from workspace metadata area.</strong> Feature and plug-in
configuration state is currently stored in the metadata subdirectory of each
workspace. This has the drawback that product configuration actions done in
one workspace do not carry over to other workspaces. Configuration state should
be moved out of the workspace into the install directory (single-user installs)
or to a dedicated read-write product configuration area (shared multi-user
installs). This would mean that configuration states would be in a known location
for external tools to find. Different workspaces might still have different
configurations, which could be achieved by referencing a named configuration
state stored centrally. [Platform Update] [Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37686">37686</a>)</p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject, Rich Client Platform theme)</h4>
<p>The following work items are being actively investigated, but we are not yet
able to promise any solution for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
adding and removing plug-ins dynamically.</strong> Installation and configuration
of features and plug-ins currently only happens during Eclipse Platform startup.
The plug-in registry should be made dynamic so that features and plug-ins
can be added or removed without necessarily having to restart Eclipse. This
will also entail adding mechanisms for handling the arrival and departure
of extensions and extension points. Additional mechanisms such as services
will be added to support the dynamic programming model. Alternative runtimes
(e.g., OSGi) which offer explicit support for dynamic components will also
be investigated and used as appropriate. Plug-in developers will likely require
additional support from PDE in writing and debugging well-behaved dynamic
plug-ins. [Platform Core, PDE] [Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37687">37687</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Allow
plug-in deactivation.</strong> In order to scale to a large number of plug-ins,
Eclipse does not activate a plug-in until its code is actually needed. However,
once activated a plug-in remains active for the remainder of the session.
Unfortunately, this means that an active plug-in will occupy memory space
for its code and objects even if it is only used occasionally. Many users
have sessions lasting days or weeks, and this bloat taxes processor memory
and JVM performance. The analogy is a long play where the actors enter the
stage on cue, but cannot leave it until the play is over. The Eclipse Platform
should support plug-ins that can be safely deactivated when the user needs
to recover valuable memory space. Another alternative is to provide a way
to quietly shutdown and restart the Platform. [Platform Core, Platform UI]
[Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36956">36956</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Add a
security model.</strong> Security needs are pervasive. The Eclipse Platform
should provide the basic framework for a security mechanism that can be used
by all plug-ins, including a simple credentials store and user authentication.
Additionally, key parts of the Platform itself should be secured, such as
the ability to install plug-ins, which might need to be restricted in certain
products or for certain users. [Platform Core, Platform Update] [Theme: Rich
client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37692">37692</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
product branding.</strong> Eclipse-based products need the ability to adopt
a product-specific look and/or apply corporate branding. Eclipse should provide
mechanisms to allow such customization. This must be done in such a way that
plug-ins can be developed independent of any particular look, and can be shared
across products with different looks. [Platform UI, SWT] [Theme: Rich client
platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37693">37693</a>)</p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, Rich Client Platform theme)</h4>
<p>These items are next in line for this release. As committers complete their
assigned tasks, or additional help becomes available, some of these items may
be committed for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Provide update
manager operations API </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37688">37688</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Allow uninstalling
features </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37689">37689</a>)</p>
</blockquote>
<h3><a name="OtherPlatform">Other Eclipse Platform Items</a></h3>
<h4>Committed Items (Eclipse Platform subproject, no theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
SWT accessibility support.</strong> In Eclipse 2.1, SWT controls tap in to
the MSAA 1.3 accessibility support, allowing accessible UIs to be built with
SWT on Windows. SWT accessibility support should be extended to GTK operating
environments, and updated on Windows for MSAA 2.0. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37694">37694</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve
action contributions.</b> The current action contribution story is diverse
and complex, and the interactions between key bindings and retargetable
actions, unclear. Eclipse should unify the action contribution support,
provide simplified support for key bindings, and clarify the interactions
between key bindings and retargetable actions. Eclipse should also support
new types of actions contributions, such as combo boxes in toolbars, and
enable additional UI customization. [Platform UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36968">36968</a>)</p>
<p>(2.1 deferred item) <b>Improve SWT support for right-to-left languages.</b>&nbsp;Allow
the appropriate widget orientation for right-to-left languages. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36951">36951</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
UI guidelines.</strong> The current Eclipse UI guidelines are somewhat dated
and do not cover as much as they need to. Eclipse should provide comprehensive
UI guidelines so that plug-in developers can create plug-ins with UIs that
fit well into the overall Eclipse workbench (a subset of these guidelines
would likely apply to general applications built with Eclipse). [Platform
UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37695">37695</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Remove
dependency on Xerces.</strong> The Xerces plug-in currently provides XML support
for the Eclipse platform. XML support is now incorporated into J2SE 1.4, and
the presence of the Xerces plug-in can create conflicts. Eclipse Platform
should consistently use the built-in XML support that ships with JDK 1.4,
or possibly an alternative XML parser such as <a href="http://www.xmlpull.org/">XMLPull</a>
which has a much smaller footprint. [Platform Core] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37696">37696</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
Ant.</strong> Eclipse should allow the option of running Ant in a separately-specified
JVM. The Ant editor should support refactoring inside Ant scripts. [Ant Core,
Ant UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37697">37697</a>)</p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject, no theme)</h4>
<p>The following work items are being actively investigated, but we are not yet
able to promise any solution for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Provide improved
table and table tree widgets. </b> Eclipse customers are finding that the
existing table and table tree custom SWT widgets lacks required functionality,
exhibit undesirable layout and resizing behavior, and are generally ill-suited
for presenting large data models. Their largely unsuccessful attempts to define
their own custom table tree widget have shown it to be a very challenging
task requiring expert-level knowledge of SWT. SWT should provide improved
table and table tree widgets. [SWT, Platform UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37998">37998</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
feature model and build support.</strong> The current nested feature structure
is static and unconditional. This makes nested features hard for developers
to manage (version brittleness, platform-specific feature ids) and greatly
increases the download size of service releases. We should allow all included
features and a feature's required plug-ins to be conditionalized, and improve
PDE to build nested features and fill in constituent version numbers at build
time. [Platform Core, Platform Update, PDE] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37713">37713</a>)</p>
</blockquote>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
team control over resource operations.</strong> Eclipse currently provides
limited hooks (edit/save, move/delete) so that team providers can control
or influence operations on resources in the workspace. However, there are
some aspects and operations over which team providers have little or no influence,
such as resource creation and copying. Eclipse should offer team providers
better control over resource operations. [Platform Core, Platform Team] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37722">37722</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
logical resources.</strong> The Eclipse Platform supports a strong physical
view of projects, files, and folders in the workspace. However, there are
many situations where a physical view is not the most salient or useful for
many purposes. In some cases, multiple distinct objects happen to be stored
in a single file, like an archive. Conversely, in other cases, something that
is logically a single object is stored across multiple files. This discrepancy
between logical and physical creates problems for common operations such as
searching, comparing, and versioning, which need to work in the physical realm.
Eclipse should support some way of mapping between a logical view and the
physical organization of files on disk. [Platform Core, Platform UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">37723</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Provide
Swing interoperability.</strong> Eclipse plug-in developers often have existing
Swing-based UIs that they would like to integrate with Eclipse. Eclipse should
provide a wrapper that allows Swing widgets to be embedded within a SWT UI.
[SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37724">37724</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Port
SWT to 64-bit operating environments. </strong>SWT currently only runs on
32-bit operating environments. SWT should be ported to run on current 64-bit
operating environments. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37721">37721</a>)</p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, no theme)</h4>
<p>These items are next in line for this release. As committers complete their
assigned tasks, or additional help becomes available, some of these items may
be committed for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
HTML help pages in archives </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37698">37698</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve structure
of existing documentation </b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36964">36964</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve update
manager downloading </b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37699">37699</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Provide one-click
update for Eclipse builds </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37701">37701</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve organizational
control over product updates </b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37702">37702</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Provide
working sets for help infocenter </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37703">37703</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
GUI test tools </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37704">37704</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
team API </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37705">37705</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
native skinning in SWT </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37706">37706</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Make SWT
work in a browser</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37707">37707</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Complete
Mac OS X port </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37708">37708</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
OpenGL </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37709">37709</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Support
MDI </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37710">37710</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
message bundles </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37712">37712</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Allow
infocenter to run on existing app server </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37714">37714</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
plug-in registry </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37715">37715</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Provide
common command infrastructure </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37716">37716</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Provide
better examples and snippets </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37717">37717</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong> Improve
support for multi-page editors </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37718">37718</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Unify
editors and views </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37719">37719</a>)</p>
</blockquote>
<h4>Rejected Items (Eclipse Platform subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse Platform subproject.)
<h2> <a name="JDT">Java development tools (JDT) subproject</a></h2>
<p><a href="http://www.eclipse.org/jdt/index.html"> Java development tools</a>
(JDT) implements a Java IDE based on the Eclipse Platform. The following work
items reflect new features of JDT, or areas where existing features will be
significantly reworked. The kinds of changes under consideration for the next
release of JDT address two general themes. The committed, proposed, and deferred
plan items are grouped in sections by theme:</p>
<ul>
<li><a href="#ThemeJavaFamily">Extended Java family theme</a> - Generalizing
JDT to handle more than just Java source files.</li>
<li><a href="#ThemeJDTUserExperience">User experience theme</a> - Improving
JDT from the point of view of the end user writing Java code.</li>
</ul>
<p>In addition, there are important Eclipse Platform improvements that do not
naturally fit into either of the above themes.</p>
<ul>
<li><a href="#OtherJDT">Other JDT items</a></li>
</ul>
<h3><a name="ThemeJavaFamily">Theme: Extended Java Family</a></h3>
<p>Generalize JDT to handle more members of the Java family than just Java source
files. This includes widening to handle Java-like languages (such as JSP and
SQLj), and embracing non-Java files containing references to Java language elements
(such as plug-in manifest files and J2EE deployment descriptors).</p>
<h4>Committed Items (Eclipse JDT subproject, Extended Java Family theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve support
for Java-like source files.</b> JSP and SQLj are two instances of languages
that use Java syntax. Eclipse should provide better support for Java-like
source files. For instance, it should be possible to index these files so
that Java search can find the Java declarations and references within; it
should be possible to use Java code assist on the Java passages; refactoring
should be able to take these files into account; the debugger should be able
to step through the Java passages (<a href="http://jcp.org/en/jsr/detail?id=045" target="_blank">JSR-045</a>);
error highlighting should be supported across sections; etc. [JDT Core, JDT
UI, JDT Debug] [Theme: Extended Java family] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36939">36939</a>)</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <b>Support Java
references outside Java code.</b> References to Java elements in particular
classes can show up in specific kinds of non-Java source files, such as plug-in
manifest files (plugin.xml), extension point schema files, and Java launch
configurations in the workspace. These references should also participate
in Java operations like search, move, rename, and other refactoring operations.
JDT will surface APIs that enable other plug-ins to contribute to and participate
in these operations. [JDT Core, JDT UI, JDT Debug, PDE] [Theme: Extended Java
family] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37937">37937</a>)</p>
</blockquote>
<h4>Proposed Items (Eclipse JDT subproject, Extended Java Family theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse JDT subproject, Extended Java Family theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h3><a name="ThemeJDTUserExperience">Theme: User Experience</a></h3>
<p>Improve JDT from the point of view of the end user reading, writing, and navigating
in Java code.</p>
<h4>Committed Items (Eclipse JDT subproject, User Experience theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Present logical
view of Java objects in debugger.</b> The current debugger always presents
the internal structure of Java objects. For instances of standard data structures
like java.util.HashMap, the Java debugger should be able to present a higher
level logical view of the object (i.e., to show it as a table of key-to-value
mappings). [JDT Debug] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36942">36942</a>)</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <b>Improve refactoring.</b>
JDT should add new refactorings, such as add parameter, convert constructor
to factory method, and extract superclass. JDT should also allow other plug-ins
to contribute specialized refactoring operations, and provide refactoring
APIs and infrastructure to make it possible for them to do so. [JDT Core,
JDT UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36943">36943</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
code formatter.</strong> JDT should provide a new code formatter implementation
that is more flexible and supports many more styles. [JDT Core] [Theme: User
experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37657">37657</a>)</p>
</blockquote>
<h4>Proposed Items (Eclipse JDT subproject, User Experience theme)</h4>
<p>The following work items are being actively investigated, but we are not yet
able to promise any solution for this release:</p>
<blockquote>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
editor code navigation.</strong> The Java editor should allow the user to
navigate in the type hierarchy from a selected element. For instance, the
editor should show override indicators (currently shown only in the outliner
view), and allow direct navigation to the declaration of the overridden method.
The editor should also provide more information about the currently selected
element such as all referenced types, call sites, overriders, implementers,
declaration. [JDT UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37658">37658</a>)</p>
</blockquote>
<h4>Deferred Items (Eclipse JDT subproject, User Experience theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h3><a name="OtherJDT">Other JDT Items</a></h3>
<h4>Committed Items (Eclipse JDT subproject, no theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
shared working copies.</strong> There is mechanism that allows working copies
of source files to be analyzed in the context of the rest of the Java model.
Currently, shared working copies are hard to manage. Eclipse should simplify
the management of working copies so that they can be used more transparently.
[JDT Core] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37659">37659</a>)</p>
</blockquote>
<h4>Proposed Items (Eclipse JDT subproject, no theme)</h4>
<p>The following work items are being actively investigated, but we are not yet
able to promise any solution for this release:</p>
<blockquote>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <b>Add early
support for J2SE 1.5 features.</b> The next feature release of J2SE is version
1.5 (&quot;Tiger&quot;), targeted to ship in the first half of 2004. While
the contents of this release are still under discussion (<a href="http://jcp.org/en/jsr/detail?id=176" target="_blank">JSR-176</a>),
this release is expected to contain extensions to the Java language, including
generic types (<a href="http://jcp.org/en/jsr/detail?id=014" target="_blank">JSR-014</a>),
enumerations, autoboxing, enhanced for loops, static imports (all <a href="http://jcp.org/en/jsr/detail?id=201" target="_blank">JSR-201</a>),
metadata facility (<a href="http://jcp.org/en/jsr/detail?id=175">JSR-175</a>),
and compiler APIs (<a href="http://jcp.org/en/jsr/detail?id=199" target="_blank">JSR-199</a>).
Supporting these new language and compiler features will require major changes
to the Eclipse Java compiler, JDT Core APIs, and JDT UI, and may suggest new
Java 1.5-specific refactorings. Although Eclipse 3.0 might ship before J2SE
1.5 does, Eclipse should contain early support for J2SE 1.5 features wherever
possible [JDT Core, JDT UI, JDT Debug] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36938">36938</a>)</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Harmonize
Java source manipulation.</b> The Java model is currently implemented in terms
of JDOM, an early precursor of the AST facility added in 2.0. JDT will move
to an AST-based implementation of the Java model, and deprecate JDOM. [JDT
Core] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36941">36941</a>)</p>
</blockquote>
<h4>Deferred Items (Eclipse JDT subproject, no theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Rejected Items (Eclipse JDT subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse JDT subproject.)
<h2> <a name="PDE">Plug-in development environment (PDE) subproject</a></h2>
The <a href="http://www.eclipse.org/pde/index.html"> plug-in development environment</a>
(PDE) consists of&nbsp;tools for developing plug-ins for the Eclipse Platform.
The following work items reflect new features of PDE, or areas where existing
features will be significantly reworked.
<h4>Committed Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse PDE subproject)</h4>
<p>The following work items are being actively investigated, but we are not yet
able to promise any solution for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Add JUnit
support for testing plug-ins.</strong> PDE should include JUnit-based support
for testing plug-ins (an early version of this support is found in the optional
<a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-ui-home/plugins/org.eclipse.jdt.junit/index.html">org.eclipse.pde.junit</a>
plug-in). (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37663">37663</a>)</p>
</blockquote>
<h4>Deferred Items (Eclipse PDE subproject)</h4>
<p>These items are next in line for this release. As committers complete their
assigned tasks, or additional help becomes available, some of these items may
be committed for this release:</p>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Help developers
tune plug-in performance </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36944">36944</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <b>Support context-sensitive
help for plug-ins </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36945">36945</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
PDE model implementation </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37660">37660</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
PDE editors </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37661">37661</a>)<br>
(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improve
plug-in debugging </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37662">37662</a>)</p>
</blockquote>
<h4>Rejected Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse PDE subproject.)
</body>
</html>