Google Git
Sign in
eclipse / gerrit / www.eclipse.org / eclipse / 878e61f93c04d7726558c26490e29c22c07ca883 / . / development / eclipse_project_plan_2_2.html
blob: 20be8dad9af48861c8054cda889a09494d4591d7 [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 2.2 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>
<h1> Eclipse Project<br>
DRAFT 2.2 Plan</h1>
<p><font size="+2"><em>This document is obsolete. The 2.2 release has been renamed
the 3.0 release (<a href="eclipse_project_plan_3_0.html">3.0 plan</a>).</em></font></p>
<p>Last revised Friday, December 20, 2002 (<img border="0" src="new.gif" width="12" height="12">
marks interesting changes over the <a href="http://eclipse.org/eclipse/development/eclipse_project_plan_2_1.html">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, designated release 2.2.
<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
a title and a concise summary (usually a single paragraph) that explains the
work item at a suitably high enough level so that everyone can readily
understand what the work item is without having to understand the nitty-gritty
details (which can be hashed out elsewhere).&nbsp;
<p>Not all plan items represent the same amount of work; some may be quite large,
others, quite small. Some plan items may involve work that is localized to a
single Platform component; others may involve coordinated changes to several
components; other may pervade the entire Platform.
<p>With the previous release as the starting point, this is the plan for how we
will enhance and improve it. Fixing bugs, improving test coverage, documentation,
examples, 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>Proposed</b> plan item - A proposal for an aspect to work on for the
release. After due consideration, a proposal will either be committed,
rejected, or deferred.</li>
<li><b>Committed</b> plan item - A committed plan item is one that we have decided
to address for the release.</li>
<li><b>Deferred</b> plan item - A reasonable proposal that did not make it in
to this release for some reason is marked as deferred with a brief note as
to why they were deferred. Deferred plan items may resurface as proposed plan
items at a later point.</li>
<li><b>Rejected</b> plan item - Plan items that were proposed but judged unworkable
are marked as rejected plan items, with an accompanying summary of why they
were dismissed. Keeping track of rejected items avoids repeating the discussion.</li>
</ul>
<h2>Release deliverables</h2>
<p>The release deliverables have the same form as previous releases, namely:
<ul>
<li>Source code release for Eclipse Project, available as versions tagged &quot;R2_2&quot;
in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS repository</a>.</li>
<li>Eclipse Project SDK (includes Platform, JDT, and PDE source zips)
(downloadable).</li>
<li>Eclipse Platform runtime binary distribution (downloadable).</li>
<li>JDT runtime binary distribution (downloadable).</li>
<li>Eclipse SDK Examples (downloadable).</li>
</ul>
<h2><a name="Milestones"></a>Release milestones</h2>
<p>Release milestone occurring at roughly
5 week intervals exist to facilitate
coarse-grained planning and staging. Assuming 2.2 development commences on April 1,
2003, the milestones for 2003 are:</p>
<ul>
<li>Friday May 2, 2003 - Milestone 1 - (2.2 M1) - stable build reflecting progress</li>
<li>Friday June 6, 2003 - Milestone 2 - (2.2 M2) - stable build reflecting progress</li>
<li>Friday August 1, 2003 - Milestone 3 - (2.2 M3) - stable build reflecting
progress</li>
<li>Friday September 12, 2003 - Milestone 4 - (2.2 M4) - stable build reflecting
progress</li>
<li>Friday October 17, 2003 - Milestone 5 - (2.2 M5) - stable build reflecting
progress</li>
<li>Friday November 21, 2003 - Milestone 6 - (2.2 M6) - stable build reflecting
progress</li>
</ul>
<p> (Note that the two mid-summer milestones are extended by two weeks each to
allow for roughly half the development team to be away on vacation.)</p>
<p> Our target
is to complete 2.2 early 1Q2004. 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 2.2 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>Eclipse SDK 2.2 will be tested and validated on the following Java 2
Platform implementations:</p>
<table width="91%" border="1">
<tbody>
<tr>
<td width="21%"><b>Operating system</b></td>
<td width="18%"><b>Processor architecture</b></td>
<td width="73%"><b>Java 2 Platforms</b></td>
</tr>
<tr>
<td width="21%" rowSpan="2">Microsoft® Windows®</td>
<td width="18%" rowSpan="2">Intel x86</td>
<td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Microsoft
Windows <i>[exact version TBD]</i></td>
</tr>
<tr>
<td width="73%">IBM 32-bit SDK for Windows, Java 2 Technology Edition, version
1.4 <i>[exact version TBD]</i></td>
</tr>
<tr>
<td width="21%" rowSpan="2">Linux</td>
<td width="18%" rowSpan="2">Intel x86</td>
<td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Linux
x86 <i>[exact version TBD]</i></td>
</tr>
<tr>
<td width="73%">IBM Developer Kit for Linux, Java 2 Technology Edition,
version 1.4 <i>[exact version TBD]</i></td>
</tr>
<tr>
<td width="21%">Sun Solaris</td>
<td width="18%">SPARC</td>
<td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Solaris
SPARC <i>[exact version TBD]</i></td>
</tr>
<tr>
<td width="21%">HP HP-UX</td>
<td width="18%">hp9000 PA-RISC</td>
<td width="73%"><span class="header">HP-UX SDK for the Java 2 platform,
version 1.4 for hp9000 PA-RISC</span> <i>[exact version TBD]</i></td>
</tr>
<tr>
<td width="21%">IBM® AIX</td>
<td width="18%">PowerPC</td>
<td width="73%">IBM Developer Kit for AIX, Java 2 Technology Edition, version
1.4 <i>[exact version TBD]</i></td>
</tr>
<tr>
<td width="21%">Apple® Mac® OS</td>
<td width="18%">PowerPC</td>
<td width="73%">Java 2 Standard Edition 1.4 for Mac OS X <i>[exact version
TBD]</i></td>
</tr>
<tr>
<td width="21%"><span class="title">QNX</span>®<span class="title">
Neutrino</span>®<span class="title"> RTOS</span></td>
<td width="18%">Intel x86</td>
<td width="73%">IBM J9 VM for QNX <i>[exact version TBD]</i></td>
</tr>
</tbody>
</table>
<p><span class="header">The following table describes the combinations of operating
system and Java 2 Platform used when testing the Eclipse SDK configurations.
The status column indicates the level of testing: &quot;Primary&quot; means
a full tested configuration; &quot;</span>Secondary&quot; means a configuration
which is only lightly tested; &quot;Untested&quot; means a configuration that
has received no testing, but which should work; &quot;As-is&quot; means a configuration
that has received no testing, and which may or may not work. The &quot;As-is&quot;
designation is used for operating environments nearing the end of their supported
life; bugs that show up only in &quot;As-is&quot; configurations of Eclipse
are unlikely to get fixed.</p>
<table height="415" width="91%" border="1">
<tbody>
<tr>
<td width="11%" height="32"><b>Window system</b></td>
<td width="28%" height="32"><b>Java 2 Platform<br>
(see above table)</b></td>
<td width="42%" height="32"><b>Operating Environment</b></td>
<td width="19%" height="32"><b>Testing Status</b></td>
</tr>
<tr>
<td width="11%" height="104" rowSpan="5">Win32</td>
<td width="28%" height="104" rowSpan="5">Windows on Intel x86</td>
<td width="42%" height="16">Windows XP</td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="42%" height="16">Windows 2000</td>
<td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12">
Secondary</td>
</tr>
<tr>
<td width="42%" height="16">Windows ME</td>
<td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12">
Untested</td>
</tr>
<tr>
<td width="42%" height="16">Windows 98SE</td>
<td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12">
As-is</td>
</tr>
<tr>
<td width="42%" height="16">Windows NT</td>
<td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12">
As-is</td>
</tr>
<tr>
<td width="11%" height="152" rowSpan="6">Motif</td>
<td width="28%" height="86" rowSpan="3">&nbsp;
<p>Linux on Intel x86</p>
<p>&nbsp;</p>
</td>
<td width="42%" height="25">RedHat Linux x86 <i>[version TBD]</i></td>
<td width="19%" height="25">Primary</td>
</tr>
<tr>
<td width="42%" height="25">SuSE Linux x86 <i>[version TBD]</i></td>
<td width="19%" height="25">Primary</td>
</tr>
<tr>
<td width="42%" height="24">Other Linux <i>[version TBD]</i></td>
<td width="19%" height="24">Untested</td>
</tr>
<tr>
<td width="28%" height="16">Solaris on SPARC&nbsp;</td>
<td width="42%" height="16">Sun Solaris SPARC <i>[version TBD]</i></td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="28%" height="16">HP-UX on hp9000 PA-RISC</td>
<td width="42%" height="16">HP-UX hp9000 <i>[version TBD]</i></td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="28%" height="16">AIX on PowerPC</td>
<td width="42%" height="16">IBM AIX on PowerPC <i>[version TBD]</i></td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="11%" height="81" rowSpan="4">GTK</td>
<td width="28%" height="81" rowSpan="4">Linux on Intel x86</td>
</tr>
<tr>
<td height="15">RedHat Linux x86 <i>[version TBD]</i></td>
<td height="15">Primary</td>
</tr>
<tr>
<td width="42%" height="16">SuSE Linux x86 <i>[version TBD]</i></td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="42%" height="16">Other Linux <i>[version TBD]</i></td>
<td width="19%" height="16">Untested</td>
</tr>
<tr>
<td width="11%" height="16">Carbon</td>
<td width="28%" height="16">Mac OS X on PowerPC</td>
<td width="42%" height="16">Mac OS X <i>[version TBD]</i></td>
<td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12">
Primary</td>
</tr>
<tr>
<td width="11%" height="16">
Photon®</td>
<td width="28%" height="16">IBM J9 VM for QNX</td>
<td width="42%" height="16">QNX Neutrino RTOS <i>[version TBD]</i></td>
<td width="19%" height="16">Primary</td>
</tr>
</tbody>
</table>
<h4>Internationalization</h4>
<p>The Eclipse Platform is designed as the basis for internationalized products.
The user interface elements provided by the Eclipse SDK components, including
dialogs and error messages, are externalized. The English strings are provided
as the default resource bundles.</p>
<p>Latin-1 locales are supported by the Eclipse SDK on all of the above
operating environments; DBCS 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 2000 and XP only. Note that GB 18030 also requires locale and character
encoding support from the Java 2 Runtime Environment version 1.4.
<p>German and Japanese locales have been 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>
Eclipse 2.2 will be upwards compatible with Eclipse 2.0 and 2.1.</p>
<h3>
Compatibility of Release 2.2 with 2.0 and 2.1</h3>
Eclipse SDK 2.2 will be upwards compatible with Eclipse SDK 2.0 and 2.1 to the
greatest extent possible. We anticipate a small number of areas where slavishly
maintaining compatibility would not be in the best interests of the Platform or
its clients. All such exceptions will be noted in the 2.2 release notes so that
clients can assess the impact of these changes on their plug-ins and products.<p><b>API Contract Compatibility:</b> Eclipse SDK 2.2 will be upwards contract-compatible
with Eclipse SDK 2.0 and 2.1 unless noted. This means that programs in full compliance
with contracts specified in Eclipse SDK 2.0 or 2.1 APIs will automatically be in
full compliance with Eclipse SDK 2.2 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 2.2 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 2.2 will be upwards
binary-compatible with Eclipse SDK 2.0 and 2.1 unless noted. This means that plug-ins
built for Eclipse SDK 2.0 or 2.1 will continue to work correctly in Eclipse
SDK 2.2 without change. Downward plug-in compatibility is not supported. Plug-ins
for Eclipse SDK 2.2 are unlikely to be usable in Eclipse SDK 2.0 or 2.1. Plug-ins
with hard-coded references in their plug-in manifest file to 2.0 or 2.1 versions of
prerequisite Eclipse Project plug-ins will work in 2.2 provided the version match
rule is &quot;greaterOrEqual&quot;
or &quot;compatible&quot; (the default); references
using &quot;perfect&quot; or &quot;equivalent&quot; match rules will be broken. 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 2.2 will be upwards source-compatible
with Eclipse SDK 2.0 or 2.1 unless noted. This means that source files written
to use Eclipse SDK 2.0 or 2.1 APIs can be successfully compiled and run against Eclipse SDK
2.2 APIs. Since source incompatibilities are easy to deal with,
maintaining source compatibility is considered much less important than maintaining
contract and binary compatibility. Downward source compatibility is not supported.
If source files use new Eclipse SDK APIs, they will not be usable with an earlier
version of the Eclipse SDK.
<p><b>Workspace Compatibility:</b> Eclipse SDK 2.2 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
2.2 and upgraded to a 2.2 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 2.2 should provide similar upwards compatibility for their hidden and visible
workspace metadata created by earlier versions; 2.2 plug-in developers are responsible
for ensuring that their plug-ins recognize 2.2, 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 2.2 will be unusable with an earlier version
of Eclipse SDK.&nbsp;Visible metadata files created (or overwritten) by Eclipse
SDK 2.2 will generally be unusable with earlier versions of Eclipse SDK.&nbsp;&nbsp;
<p><b>Non-compliant usage of API's</b>: All non-API methods and classes, and certainly
everything in a package with &quot;internal&quot; in its name, are considered
implementation details which may vary between operating environment and are
subject to change without notice. Client plug-ins that directly depend on anything
other than what is specified in the Eclipse SDK API are inherently unsupportable
and receive no guarantees about compatibility within a single release much less
with an earlier 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 <a href="http://www.eclipse.org/eclipse/">Eclipse Project</a> consists of
3 subprojects. Each subproject is covered in its own section:
<blockquote><a href="#Platform">Eclipse Platform</a><br>
<a href="#JDT">JDT - Java development tools</a><br>
<a href="#PDE">PDE - Plug-in development environment</a></blockquote>
<p>For each subproject, the items listed reflect new features of the Eclipse Platform,
or areas where existing features will be significantly reworked. Each item indicates
the components affected by that work item (many items involve coordinated changes
to several components).
<h3>
<a name="Platform">Eclipse Platform subproject</a></h3>
The <a href="http://www.eclipse.org/platform/index.html">Eclipse
Platform</a> provides the most fundamental building blocks. The following items
reflect new features of the Eclipse Platform, or areas where existing features
will be significantly reworked.
<h4>Committed Items (Eclipse Platform subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject)</h4>
<blockquote>
<p> (2.1 deferred item) <b>Add cheat sheets</b>.&nbsp; 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]</p>
<p> (2.1 deferred item) <b>Add </b><b>table of contents support to </b><b>wi</b><b>zards.</b>
Extend the workbench wizard framework to allow Eclipse wizard developers to
provide much more substantial and significant user feedback. [Platform UI]</p>
<p> (2.1 deferred item) <b>Support floating toolbars and views.</b> Allow the
user to customize the workbench by creating floating toolbars and views. [Platform
UI]</p>
<p> (2.1 deferred item) <b>Allow editors to open files outside workspace.</b>
A common request is to be able to open a file that is not part of the workspace
using Eclipse. 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]</p>
<p> (2.1 deferred item) <b>Improve serviceability. </b>Progress was made at
improving serviceability in 2.0; however, additional improvements are needed,
particularly in dealing with error conditions and reporting them in an appropriate
manner. [Platform Core, SWT, Platform UI]<br>
<br>
(2.1 deferred item) <b>Improve file encoding support.</b> Eclipse 2.0 and
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.
(Ref: <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=5399">bug 5399</a>)
[Platform Core, Platform UI, Text, Search, Compare, JDT UI, JDT Core]</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]</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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Support automation of common tasks.</b> To make it easier for users to automate
common and repetitive tasks, the user should have a simple way of recording the sequence of
actions as they perform them. The recording can be edited, saved persistently, and
played back under similar circumstances in the same or later session, or
possibly another workspace. [Platform UI, Platform Core, Platform Text, JDT
Core, JDT UI, PDE]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Reduce workbench clutter.</b> Despite efforts to ensure UI scalability
with a large bases of available tools, the Eclipse workbench still intimidates
many users with overly long menus and wide toolbars. This problem is acute in
large Eclipse-based products (e.g., IBM WebSphere Application Developer). 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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Allow plug-in deactivation.</b> 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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Support background 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.
[Platform UI, Platform Core, Platform Text, JDT Core, JDT UI, PDE]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Support workspace checkpoint and rollback.</b> Sometimes a set of
resource changes must be explored to see if they are possible or worthwhile.
When the changes do not pan out, there needs to be a way to roll back the
workspace to the prior state. Eclipse should support long workspace transactions
with the ability to checkpoint and rollback. The facility should be available to
users and programmatically (e.g., JDT refactoring). [Platform UI, Platform Core,
JDT Core, JDT UI]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Add capabilities.</b> In Eclipse 2.0 we did some early work on a
mechanism called &quot;capabilities&quot; to allow users to dynamically
configure project natures. The Eclipse Platform should expose this mechanism to
users. [Platform UI, JDT UI, PDE]</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> expanded 2.1 PDE
deferred item) <b>Add project templates.</b> Eclipse should provide a streamlined
way to create projects using templates contributed by plug-ins. These project
templates would be able to populate the projects with stock content so that
projects don't start off completely empty. PDE's current mechanism should
be generalized, pushed down into the Platform, and put to good use by JDT.
[Platform UI, JDT UI, PDE UI]</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]</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]</p>
<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. The Eclipse Platform team will
work with the community to define a new custom table and table tree widgets that will meet
their needs. [SWT, Platform UI]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Improve structure of existing documentation.</b> The Eclipse help
books are currently black boxes. There is no easy way to insert additional
material into an existing Eclipse book, such as adding a section describing a
new tool. And there is no way to incorporate portions of the Eclipse books into
some other book. The Eclipse Platform help books should be restructured in a
more modular manner by making better use of existing help system capabilities.
[Platform, JDT, PDE, Platform Help]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Provide user preferences.</b> It should be possible to store user
preferences that are not specific to a workspace separate from the workspace, so
that they can be used in any workspace. [Platform Core, Platform UI]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Evolve the Eclipse user experience.</b> The current Eclipse GUI is
solidly grounded in traditional opaque, rectangular windows. Recent advances in
UI design improve the user experience with such things as transparent overlays
and associating sounds with significant events. Eclipse 2.2 should have a new
look that makes more effective use of the capabilities of current desktop
computers. [Platform UI, JDT UI, Debug UI]</p>
<p>(<img border="0" src="new.gif" width="12" height="12">
new) <b></b> <b>Enable Eclipse to be used as a general purpose application
framework.</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 general purpose
application framework. [Platform Core, Platform UI]</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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Add a &quot;tips &amp; tricks&quot; facility.</b> Eclipse should
provide an open, flexible mechanism for offering suggestions and tips to the
user for the various tools available and active in the IDE. [Platform UI]</p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject)</h4>
<blockquote>
<p><i>None at this time.</i></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.)
<h3> <a name="JDT">Java development tools
(JDT) subproject</a></h3>
<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.
<h4>Committed Items (Eclipse JDT subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse JDT subproject)</h4>
<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. Although Eclipse 2.2 will
likely ship before J2SE 1.5 does, Eclipse should contain early support for
J2SE 1.5 features wherever possible [JDT Core, JDT UI, JDT Debug]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Improve support for Java-like source files.</b> JSP and JSQL are two
instances of languages that embed passages of Java language code. Eclipse
should provide better support for Java-like source files. For instance,
outline views should be able to show the hierarchy of Java elements; 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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Support Java references from non-Java files.</b> References to Java elements in particular classes
can show up in specific kinds of non-Java files, such as plug-in manifest
files (plugin.xml). 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]<br>
<br>
(<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]</p>
<p>
(<img border="0" src="new.gif" width="12" height="12">
new) <b>Present </b><b>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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12">
new) <b>Provide API for refactoring</b><b>.</b> JDT should allow other plug-ins to
contribute specialized refactoring operations, and provide the infrastructure
to make it possible for them to do so. [JDT Core, JDT UI]</p>
</blockquote>
<h4>Deferred Items (Eclipse JDT subproject)</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.)
<h3>
<a name="PDE">Plug-in development environment (PDE) subproject</a></h3>
The <a href="http://www.eclipse.org/pde/index.html"> plug-in development environment</a>
(PDE) consists of&nbsp;tools for developing plug-ins for the Eclipse Platform.
The following work items reflect new features of PDE, or areas where existing
features will be significantly reworked.
<h4>Committed Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse PDE subproject)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Help developers
tune plug-in performance.</b> Observing and measuring the dynamic behavior
of a plug-in is key to developing plug-ins that perform well. PDE visualizations
should help the developer understand the dynamic behavior of their running
plug-in; e.g., reason for plug-in activation, elapse time to start up, dependent
plug-ins activated, etc.</p>
</blockquote>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12">
new) <b>S</b><b>upport context-sensitive help for plug-ins.</b> All plug-in
should provide context-sensitive (F1) help for their UI components. However,
implementing F1 support is somewhat cumbersome and error prone. PDE should
provide additional support in this area, such as assigning help contexts to UI
elements, updating corresponding XML files, and checking consistency of context
ids.</p>
</blockquote>
<h4>Deferred Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><i>None at this time.</i></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>