blob: 08fc8cb9f4af5aaf6df2b67f9ee12f87e78cfd60 [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>
3.0 Plan (Final)</h1>
<p>Last revised Wednesday, June 2, 2004 (<img border="0" src="new.gif" width="12" height="12">
marks interesting changes since the <a href="eclipse_project_plan_3_0_20040428.html">previous
draft of April 28, 2004</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 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) - stable build reflecting
progress</li>
<li>Friday November 21, 2003 - Milestone 5 (3.0 M5) - initial API freeze for
breaking changes - stable build reflecting progress</li>
<li>Friday December 19, 2003 - Milestone 6 (3.0 M6) - API freeze for breaking
changes - stable build with focus on reducing the bug backlog and fixing memory
leaks</li>
<li>Friday February 13, 2004 - Milestone 7 (3.0 M7) - stable build reflecting
progress</li>
<li>Friday March 26, 2004 - Milestone 8 (3.0 M8) - stable build reflecting progress</li>
<li> Friday May 21, 2004 - Milestone 9 (3.0 M9) - stable build - feature complete
- development freeze - lock down and testing begins</li>
</ul>
<p><img border="0" src="new.gif" width="12" height="12"> Lock down and testing
then begins with M9, and progress through a series of test-fix passes against
candidates releases. Release candidate builds are planned as follows (M9 is
release candidate 0):</p>
<ul>
<li>Friday May 28, 2004 - Release Candidate 1 - (3.0 RC1)</li>
<li>Friday June 11, 2004 - Release Candidate 2 - (3.0 RC2)</li>
<li>Friday June 18, 2004 - Release Candidate 3 - (3.0 RC3)</li>
<li>Friday June 25, 2004 - Release Candidate 4 - (3.0 RC4)</li>
</ul>
<p> Depending on the circumstances, we may add additional release candidate builds
or fine-tune the schedule. The 3.0 release is targeted for the week of June
28, 2004. See the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-project-home/plans/3_0/freeze_plan.html">Eclipse
3.0 Endgame Plan</a> for further details. 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. 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>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="821" border="1">
<tr bgcolor="#CCCCCC">
<th colspan="4">
<div align="center">
<b><font size="+1">Eclipse Reference Platforms</font></b>
</div>
</th>
</tr>
<tr>
<td width="205"><b>Operating system</b></td>
<td width="76"><b>Processor architecture</b></td>
<td width="59"><b>Window system</b></td>
<td width="453"><b>Java 2 Platform</b></td>
</tr>
<tr>
<td width="205">Microsoft Windows XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">Sun Java 2 SDK, Standard Edition, version 1.4.2_03 for Microsoft
Windows</td>
</tr>
<tr>
<td width="205">Microsoft Windows XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">
<p>IBM 32-bit SDK for Windows, Java 2 Technology Edition, Version 1.4.1</p>
</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux WS 3</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux WS 3</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">IBM 32-bit SDK for Linux on Intel architecture, Java 2
Technology Edition, Version 1.4.1</td>
</tr>
<tr>
<td width="205"> SuSE Linux 8.2</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86</td>
</tr>
<tr>
<td width="205"> SuSE Linux 8.2</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">IBM 32-bit SDK for Linux on Intel architecture, Java 2
Technology Edition, Version 1.4.1</td>
</tr>
<tr>
<td width="205"> Sun Solaris 8</td>
<td width="76">SPARC</td>
<td width="59">Motif</td>
<td width="453">Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Solaris SPARC</td>
</tr>
<tr>
<td width="205">HP HP-UX 11i</td>
<td width="76">hp9000<br>
PA-RISC</td>
<td width="59">Motif</td>
<td width="453"><span class="header">HP-UX SDK for the Java 2 platform, version
1.4.2.00 for hp9000 PA-RISC</span></td>
</tr>
<tr>
<td width="205" height="21">IBM AIX 5L Version 5.2</td>
<td width="76">PowerPC</td>
<td width="59">Motif</td>
<td width="453">
<p>IBM 32-bit SDK for AIX, Java 2 Technology Edition, Version 1.4.1</p>
</td>
</tr>
<tr>
<td width="205">Apple Mac OS X 10.3</td>
<td width="76">PowerPC</td>
<td width="59">Carbon</td>
<td width="453">Java 2 Standard Edition 1.4.1 for Mac OS X</td>
</tr>
</table>
<p>Although untested, Eclipse should work fine on other OSes that support the
same window system. For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT
HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux
systems: version 2.2.1 of the GTK+ widget toolkit and associated librares (GLib,
Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on other Linux systems:
Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.</p>
<p> An early access version of Eclipse is available for 64-bit Linux GTK. Testing
has been limited to early access 64-bit J2SEs running on AMD64 processors.</p>
<p> SWT is also supported on the QNX Neutrino operating system, x86 processor,
Photon window system, and IBM J9 VM version 2.0. Eclipse 3.0 on Windows or Linux
can be used cross develop QNX applications. (Eclipse 3.0 is unavailable on QNX
because there is currently no 1.4 J2SE for QNX.)</p>
<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> SWT fully supports BIDI on Windows (only). On Linux GTK, SWT supports entering
and displaying BIDI text.</p>
<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>
<h2><a name="Compatibility"></a>Compatibility with Previous Releases</h2>
<p>Eclipse 3.0 will be compatible with Eclipse 2.0 and 2.1 to the greatest
extent possible.</p>
<h3>Compatibility of Release 3.0 with 2.0 and 2.1</h3>
<p>Eclipse 3.0 will be compatible with Eclipse 2.0 and 2.1 to the greatest extent
possible. The nature and scope of some of the key plan items are such that the
only feasible solutions would break compatibility. Since breaking changes are
a disruption to the Eclipse community, they cannot be taken lightly. We (the
Eclipse PMC) will have an open discussion with the community before approving
a proposed breaking change for inclusion in 3.0. In other regards, Eclipse 3.0
will be compatible with 2.0 and 2.1. We also aim to minimize the effort required
to port an existing plug-in to the 3.0 APIs. We will provide a comprehensive
<a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html" target="_top"><em>Eclipse
3.0 Porting Guide</em></a> 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
<a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html" target="_top"><em>Eclipse
3.0 Porting Guide</em></a> 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 <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html" target="_top"><em>Eclipse
3.0 Porting Guide</em></a>. Programs that use affected APIs and extension points
will need to be ported to Eclipse SDK 3.0 APIs. 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>
<p><b>Binary (plug-in) Compatibility:</b> Eclipse SDK 3.0 will be upwards binary-compatible
with Eclipse SDK 2.0 and 2.1 except in those areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html" target="_top"><em>Eclipse
3.0 Porting Guide</em></a>. Eclipse 3.0 will include additional runtime compatibility
mechanisms to provide effective binary API compatibility. Downward plug-in compatibility
is not supported. 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 <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html" target="_top"><em>Eclipse
3.0 Porting Guide</em></a>. 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 a
product based on Eclipse 3.0 will be unusable with a product based an earlier
version of Eclipse. Visible metadata files created (or overwritten) by Eclipse
3.0 will generally be unusable with earlier versions of Eclipse.
<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&amp;product=PDE&amp;product=Platform&amp;keywords=plan&amp;target_milestone=3.0&amp;target_milestone=3.0+M1&amp;target_milestone=3.0+M2&amp;target_milestone=3.0+M3&amp;target_milestone=3.0+M4&amp;target_milestone=3.0+M5&amp;target_milestone=3.0+M6&amp;target_milestone=3.0+M7&amp;target_milestone=3.0+M8&amp;target_milestone=3.0+M9">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><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)<em>
<img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
</blockquote>
<blockquote>
<p><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. [Platform Text, JDT UI]
[Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37671">37671</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>) <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Allow dynamic help content.</strong> Existing help content consists
entirely of static HTML pages. Additional flexibility would be provided by
allowing help content to include JSPs, possibly with access to the user's
Eclipse environment. [Platform Help] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37676">37676</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Simplify update manager UI.</b> User feedback indicates that the update
manager UI is too powerful and occasionally confusing to users. It should
be simplified in order to provide a clear path for the common tasks, embrace
progressively disclosure, separate update search from platform configuration
tasks, and make more economical use of screen real estate for properties.
[Platform Update] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37678">37678</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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. 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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><strong>Content-type-based infrastructure.</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 provide infrastructure support for a notion of content type
for files and resources. [Platform Core, Platform UI] [Theme: User experience]
(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=60291">60291</a>) <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><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>) <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Add cheat sheets. </b> A cheat sheet is an instance of a simple kind of
workflow support used to help the user carry out a sequence of steps. For
example, &quot;create and deploy a plug-in&quot; is a multi-step process that
could be made easier to follow if there was a guide, similar to a recipe that
would track the user's progress and provide both descriptive text that explains
the steps involved and integration with Eclipse to automate the process. The
Welcome Page editor is a simple example of a cheat sheet. Provide a standard
API for creating cheat sheets. [Platform UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36946">36946</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject, User Experience theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, User Experience theme)</h4>
<blockquote>
<p><b>Launch Eclipse editor from outside Eclipse</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=60289">60289</a>)<br>
<strong>Content-type-based editor lookup </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>)<br>
<b>Add table of contents support to wizards </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36947">36947</a>)<br>
<b>Add project templates </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36960">36960</a>)<br>
<b>Allow automation of common tasks</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37936">37936</a>)<br>
<b>Support workspace checkpoint and rollback </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36958">36958</a>)<br>
<strong>Display HTML help infopops </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37677">37677</a>)<br>
<b>Add capabilities </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36959">36959</a>)<br>
<strong>Improve local history </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37679">37679</a>)<br>
<strong>Add Eclipse automation </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37680">37680</a>)<br>
<b>Aid ongoing learning</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37666">37666</a>)<br>
<b>Provide a general purpose navigator</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36961">36961</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><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><b>Improve update manager search.</b> Update manager searches for new and
updated features are done in the Eclipse client. These searches, which can
be time- consuming, are done only on request, and the user cannot do anything
in Eclipse until the search has completed. There are several ways update manager
searches could be improved: provide update search APIs; allow searches to
run asynchronously in the background; allow background searches to be scheduled
periodically, or on startup; allow searches to be done on the server, thereby
enabling sites to provide custom search implementations. [Platform Update]
[Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37684">37684</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Improve scalability for large help books.</strong> Improve scalability
for large help books. Although the help system does deal well with large collections
of topics distributed across many books, browser performance degrades severely
when a large number of topics (2000+) are concentrated in a single book. This
performance problem needs to be addressed, possibly by lazily loading navigation
information. [Platform Help] [Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37685">37685</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p>(<img border="0" src="new.gif" width="12" height="12"> recently committed
item) <strong>Address platform-specific UI performance problems.</strong>
There is a noticeable 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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </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>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, Responsive UI theme)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> recently de-committed
item) <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>
<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><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>) <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><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>) <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Provide update manager operations API.</b> Most of the logic currently
in the update manager UI should be pushed into a new operations layer. This
operations layer would be to Update Core what JFace is to SWT. The APIs would
enable update tasks to run headless, and would enable updates to be scripted.
[Platform Update] [Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37688">37688</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Allow uninstalling features.</b> The update manager can disable features
and plug- ins, but this is done without deleting their files. The update manager
should keep track of the features and plug-ins that it installs, and fully
support uninstalling them. [Platform Update] [Theme: Rich client platform]
(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37689">37689</a>) <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject, Rich Client Platform theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, Rich Client Platform theme)</h4>
<blockquote>
<p><strong>Add a security model </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37692">37692</a>)
</blockquote>
<h3><a name="OtherPlatform">Other Eclipse Platform Items</a></h3>
<h4>Committed Items (Eclipse Platform subproject, no theme)</h4>
<blockquote>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Improve Ant.</strong> Eclipse should allow the option of running
Ant in a separately-specified JVM. [Ant Core, Ant UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37697">37697</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Support HTML help pages in archives.</b> A JAR or zip file is a convenient
way to keep the large number of HTML files of a Javadoc web together. The
Eclipse help system should also plug-ins to contribute (and refer to) HTML
pages located in archives. [Platform Help] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37698">37698</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Improve organizational control over product updates.</b> In organizations
where there are many users and installs of the same Eclipse product, the local
administrator should have ways of managing how the product installs gets updated.
For example, the local administrator should be able to proxy a remote update
site and serve up supported updates hosted locally within the organization,
thereby conserving bandwidth, minimizing download failures, and keeping things
inside the organization's firewall. [Platform Update] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37702">37702</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Provide working sets for help infocenter.</b> Persistent help working
sets were added in Eclipse 2.1. This support is not available is infocenters,
where the user must still rely on searches (which are not persisted). Persistent
working set support should be added to infocenters as well. [Platform Help]
(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37703">37703</a>) <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed for Windows,
Linux</em></p>
<p><strong>Support multi-instance views.</strong> The workbench should support
multi-instance views. A multi-instance view allows multiple instances to be
opened side-by-side in a workbench window. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50814">50814</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><strong>Provide forms-based UI toolkit.</strong> Eclipse should provide a
toolkit for building UIs similar to web page forms (a mixture of text, graphics,
and simple controls like combo boxes, buttons, and entry fields). This style
of UI is currently used for the GUI pages of PDE editors and for the Update
Manager view. This toolkit would be an optional component suitable for use
with the generic workbench in RCP configurations. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50815">50815</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)<em>
<img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Make workspace builds more scalable.</strong> Owing to the build-all-projects-one-project-at-a-time
nature of incremental project builders, large workspaces can take a long time
to build when there are extensive inter-project dependencies. The build mechanism
needs to be more scalable in such cases, possibly by introducing builds scoped
to working sets. [Platform Core, Platform UI, JDT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50816">50816</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><strong>Support GUI test tools.</strong> SWT should provide common facilties
and APIs so that GUI test tools can integrate with SWT-based UIs. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37704">37704</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject, no theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject, no theme)</h4>
<blockquote>
<p><strong>Improve team control over resource operations</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37722">37722</a>)<br>
<strong>Support logical resources</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">37723</a>)<br>
<b>Improve structure of existing documentation </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36964">36964</a>)<br>
<b>Improve update manager downloading </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37699">37699</a>)<br>
<b>Provide one-click update for Eclipse builds </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37701">37701</a>)<br>
<strong>Improve team API </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37705">37705</a>)<br>
<strong>Support native skinning in SWT </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37706">37706</a>)<br>
<strong>Make SWT work in a browser</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37707">37707</a>)<br>
<strong>Complete Mac OS X port </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37708">37708</a>)<br>
<strong>Support OpenGL </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37709">37709</a>)<br>
<strong>Support MDI </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37710">37710</a>)<br>
<strong>Improve message bundles </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37712">37712</a>)<br>
<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>
<strong>Improve plug-in registry </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37715">37715</a>)<br>
<strong>Provide common command infrastructure </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37716">37716</a>)<br>
<strong>Provide better examples and snippets </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37717">37717</a>)<br>
<strong>Improve support for multi-page editors </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37718">37718</a>)<br>
<strong>Unify editors and views </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37719">37719</a>)<br>
<b>Improve action contributions</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36968">36968</a>)<br>
<strong>Improve UI guidelines</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37695">37695</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><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </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><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><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.
[JDT UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37658">37658</a>)<em>
<img src="ok.gif" width="12" height="12"> Work completed</em> </p>
</blockquote>
<h4>Proposed Items (Eclipse JDT subproject, User Experience theme)</h4>
<blockquote>
<p><i>None at this time.</i></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><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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
</blockquote>
<h4>Proposed Items (Eclipse JDT subproject, no theme)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse JDT subproject, no theme)</h4>
<blockquote>
<p><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>)
<em><strong>NOTE: We will continue to make available early access support
for J2SE 1.5 in the form of replacement JDT plug-ins that can be installed
into Eclipse 3.0 (<a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core-home/r3.0/main.html#updates">Cheetah
download page</a>). Although this item is no longer under consideration for
the 3.0 release, the item is still high-priority and the work is ongoing.</strong></em></p>
<p><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>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><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/~checkout~/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>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Add support for new plug-in format.</strong> PDE should provide support
for developing and deploying plug-ins with explicit OSGI bundle manifests.
The goal is provide a seamless experience for developers working with a mix
of traditional and new style plug-ins. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50921">50921</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><strong>Improve PDE model implementation. </strong> PDE lazily builds detailed
models of plug- ins, plug-in fragments, features, extension point schemas.
Once loaded, these models are kept in memory until shut down. This approach
does not scale up to working with large numbers (1000s) of plug-ins. PDE model
elements should be changed to use a more lightweight representation. (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37660">37660</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
</blockquote>
<h4>Proposed Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><b>Help developers tune plug-in performance </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36944">36944</a>)<br>
<b>Support context-sensitive help for plug-ins </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36945">36945</a>)<br>
<strong>Improve PDE editors </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37661">37661</a>)<br>
<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>