blob: 7302f44b2378efa1fe016f1044d16a88a98c41a0 [file] [log] [blame]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<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.1 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
<h1>Eclipse Project<br>
INITIAL DRAFT 3.1 Plan</h1>
<p>Last revised 18:15 EDT July 29, 2004 (<img border="0" src="new.gif" width="12" height="12">
marks interesting changes over the <a href="eclipse_project_plan_3_0.html">3.0
<i>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to the </i><a href=""></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 3.0, designated release 3.1.
<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 project</a></li>
<li><a href="#JDT">Java development tools (JDT) project</a></li>
<li><a href="#PDE">Plug-in development environment (PDE) project</a></li>
<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 three projects under
the Eclipse top-level project. 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 tuning, 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. The intent of the plan is to account for all interesting feature work.
<p>The current status of each plan item is noted:
<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 or deferred.</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>
<h2><a name="Deliverables"></a>Release deliverables</h2>
<p>The release deliverables have the same form as previous releases, namely:
<li>Source code release for Eclipse Project, available as versions tagged
&quot;R3_1&quot; in the Eclipse Project <a href="">CVS
<li>Eclipse Project SDK (includes runtime binary and SDK for Platform, JDT,
and PDE) (downloadable).</li>
<li>Eclipse Platform runtime binary and SDK distributions (downloadable).</li>
<li>Eclipse RCP runtime binary and SDK distributions (downloadable).</li>
<li>JDT runtime binary and SDK distributions (downloadable).</li>
<li>PDE runtime binary and SDK distributions (downloadable).</li>
<li>Eclipse SDK Examples (downloadable).</li>
<li>SWT distribution (downloadable).</li>
<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>
<li>Friday Aug. 13, 2004 - Milestone 1 (3.1 M1) - stable build</li>
<li>Friday Sep. 24, 2004 - Milestone 2 (3.1 M2) - stable build</li>
<li>Friday Nov. 5, 2004 - Milestone 3 (3.1 M3) - stable build</li>
<li>Friday Dec. 17, 2004 - Milestone 4 (3.1 M4) - stable build</li>
<li>Friday Feb. 18, 2005&nbsp; - Milestone 5 (3.1 M5) - stable build</li>
<li>Friday Apr. 1, 2005 - Milestone 6 (3.1 M6) - stable build</li>
<p>The 3.1 release is targeted for 2Q2005. 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.1 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.1 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>
<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>
<td width="205">Microsoft Windows XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">Sun Java 2 Standard Edition, version 1.4.2_03 for Microsoft
<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 width="205"><img border="0" src="new.gif" width="12" height="12">
Microsoft Windows XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">Sun Java 2 Standard Edition 5.0 for Microsoft Windows</td>
<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 Standard Edition, 1.4.2_03 for Linux x86</td>
<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>
<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 Standard Edition, version 1.4.2_03 for Linux x86</td>
<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>
<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>
<td width="205">HP HP-UX 11i</td>
<td width="76">hp9000<br>
<td width="59">Motif</td>
<td width="453"><span class="header">HP-UX SDK for the Java 2 platform,
version for hp9000 PA-RISC</span></td>
<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 width="205">Apple Mac OS X 10.3</td>
<td width="76">PowerPC</td>
<td width="59">Carbon</td>
<td width="453"><img border="0" src="new.gif" width="12" height="12"> Java 2 Standard Edition
1.4.2 for Mac OS X</td>
<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 also available for 64-bit Linux GTK.
Testing has been limited to early access 64-bit J2SEs running on AMD64
<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.1 on Windows or Linux
can be used cross develop QNX applications. (Eclipse 3.1 is unavailable on QNX
because there is currently no 1.4 J2SE for QNX.)</p>
<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>
<h3>Compatibility of Release 3.1 with 3.0</h3>
<p>Eclipse 3.1 will be compatible with Eclipse 3.0.</p>
<p><b>API Contract Compatibility:</b> Eclipse SDK 3.1 will be upwards
contract-compatible with Eclipse SDK 3.0 except in those areas noted in the <a href="" target="_top"><em>Eclipse
3.1 Plug-in Migration Guide</em></a>. Programs that use affected APIs and extension points
will need to be ported to Eclipse SDK 3.1 APIs. Downward contract compatibility
is not supported. There is no guarantee that compliance with Eclipse SDK 3.1
APIs would ensure compliance with Eclipse SDK 3.0 APIs. Refer to <i><a href="">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.1 will be upwards
binary-compatible with Eclipse SDK 3.0 except in those areas noted in the <a href="" target="_top"><em>Eclipse
3.1 Plug-in Migration Guide</em></a>. Downward plug-in compatibility is not supported.
Plug-ins for Eclipse SDK 3.1 will not be usable in Eclipse SDK 3.0. Refer to <i><a href="">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.1 will be upwards
source-compatible with Eclipse SDK 3.0 except in the areas noted in the <a href="" target="_top"><em>Eclipse
3.1 Plug-in Migration Guide</em></a>. This means that source files written to use Eclipse
SDK 3.0 APIs might successfully compile and run against Eclipse SDK 3.1 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.1 will be upwards
workspace-compatible with Eclipse SDK 3.0 unless noted. This means that
workspaces and projects created with Eclipse SDK 3.0 can be successfully opened
by Eclipse SDK 3.1 and upgraded to a 3.1 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.1 should provide similar upwards
compatibility for their hidden and visible workspace metadata created by earlier
versions; 3.1 plug-in developers are responsible for ensuring that their
plug-ins recognize 3.1, 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.1 will be unusable with a product based
an earlier version of Eclipse. Visible metadata files created (or overwritten)
by Eclipse 3.1 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="">How
to Use the Eclipse API</a></i> for information about how to write compliant
<p><img border="0" src="new.gif" width="12" height="12"> The changes under consideration for the next release of Eclipse Platform, JDT,
and PDE address a few major themes:</p>
<li><b>Built to last </b>- Eclipse has always been a platform for delivering
integrated software tools. With a large and growing base of both free and
commercial offerings based on Eclipse, it's critical for continued success
to maintain API stability and ensure that the platform scales well. This
theme includes work to measure and improve the performance of key operations
under various loads (number of installed plug-ins, number of resources in
the workspace, etc.). This theme also includes consolidation activities
where groundwork was laid in 3.0 but needs to be completed and brought into
full use.</li>
<li><b>Simple to use</b> - The Eclipse platform needs to not only provide the
features that advanced users demand, but also be something that most users
find simple to use. This theme includes ease-of-use reviews of existing
features, and work that helps make Eclipse-based products simple to use for
users with widely-varying backgrounds and skill sets.</li>
<li><b>Rich client platform </b>- The Eclipse RCP is a Java-based application
framework for the desktop. Building on the Eclipse runtime and the modular
plug-in story, it is possible to build applications ranging from command
line tools to feature-rich applications that take full advantage of SWT's
native platform integration and the many other reusable components that the
Eclipse platform provides. This theme includes work to enhance the RCP, and
to provide PDE support for developing and deploying RCP-based applications.</li>
<li><b>J2SE 5 support</b> - This theme covers work to add full support for
J2SE 5 to JDT.</li>
<li><b>Large-scale development </b>- Large software projects are long-term
collaborations involving large teams of developers playing a variety of
roles. In order to be effective for large projects, software tools and
processes must fit well into this reality. This theme includes laying the
groundwork in the Eclipse Platform that will enable large teams to make
effective use of Eclipse-based products.</li>
<li><b>Broadening the community</b> - This theme includes work that grows
deeper roots into the various OS-specific communities, spreads Eclipse to
additional operating environments, and builds bridges to other open source
<p>Since each theme has a number of items, the committed, proposed, and deferred
plan items are grouped in sections by theme. In addition, there are a few
important Eclipse Platform improvements that do not naturally fit into any of
the above themes; these are listed separately.</p>
Each of the 3 projects under the Eclipse top-level project is covered in its
own section:
<li><a href="#Platform">Eclipse Platform project</a></li>
<li><a href="#JDT">Java development tools (JDT) project</a></li>
<li><a href="#PDE">Plug-in development environment (PDE) project</a></li>
<p>For each project, the items listed reflect new features of Eclipse 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.
<h2><a name="Platform">Eclipse Platform project</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.</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> Note: Unlike plans for
earlier releases, this plan is starting off with only a small number of items.
Additional plan items will definitely be added in subsequent plan revisions as further
requirements come in from the community.)</p>
<h4>Committed Items (Eclipse Platform project)</h4>
<p><i>None at this time.</i></p>
<h4>Proposed Items (Eclipse Platform project)</h4>
<p><b>Process improvements wrt performance.</b> For 3.1 we should get a firm
grip on speed and space performance. To do this we should (1) identify which aspects are critically
important performance-wise; (2)
establish benchmarks to quantify performance; and (3) look at ways to improve
performance. By its
nature, it's hard to say in advance what kind of improvements we'll be able
to achieve, making it difficult to make performance improvements a
release deliverable. Instead, what we need to do for 3.1 is commit to track performance from this point on.
We should carry out performance reviews (1) and create benchmarks (2) for
every component, and for any critical aspects that span components. Even if
we cannot find ways to make significant performance gains (3), the benchmarks
are still
critical to Eclipse's success to prevent backsliding in the future. The work
item is to improve our process with respect to performance. The deliverables
are the automated performance tests, the build process that collects
and publishes performance data covering all critical aspects of Eclipse, and
the committment to leverage this data to monitor speed and space performance
as part and parcel of developing Eclipse. [All Eclipse components] (<a href="">71123</a>)
[Theme: Built to last] [Note: To get things started, the PMC has asked each
component team to create their first performance test by M1.]<br>
<b>Overhaul preferences.</b> The way that Eclipse deals with preferences
should be improved. The workbench presentation of
preferences generally uses a component-oriented hierarchy, which is not always
the best choice for users. The UI should present preferences in such a way
that users can readily discover them. Some preference settings have scopes
(e.g., workspace-wide vs. per project). The UI should help the user to
visualize these scopes. For team-wide uniformity, some preferences settings
(e.g., compiler options) need to be shared (or imposed) across teams. The UI
should also facilitate this. [Platform Core; Platform UI; Text; JDT UI; JDT
Core] (<a href="">71124</a>)
[Theme: Built to last; simple to use]<br>
<strong>Logical resources.</strong> The Eclipse Platform supports a strong physical
view of projects, files, and folders in the workspace. However, there are many
situations where a physical view is not the most salient or useful for many purposes. In some cases, multiple distinct objects happen to be stored in a
single file, like an archive. Conversely, in other cases, something that is logically a single object is stored across multiple files. This
discrepancy between logical and physical creates problems for common operations such as
searching, comparing, and versioning, which need to work in the physical realm. Eclipse should support some way of mapping between a logical view and
the physical organization of files on disk. [Platform Core, Platform UI, Team]
(<a href="">37723</a>)
[Theme: Built to last; large-scale development]<b><br>
Embedding editors and views.</b> The current compare infrastructure requires a plug-in to create a
separate text editor for viewing changes between files. This is due a limitation in the workbench that
prevents editors from being embedded inside views or other controls. As a
consequence, the compare view's editors don't support the full set of features
provided by the corresponding real content-type-specific editor, and
represents a major usability problem for users switching to the
real editor to make changes and then returns to the compare view to review the
changes. Eclipse should be more flexible in the ways various editors can be
used and reused. [Platform UI, Compare, Text] (<a href="">71125</a>) [Theme: Simple to use]<br>
<b>Team policies.</b> Teams of developers working together have special needs
for ensuring the integrity and consistency of their collective work. For
example, they may have policies for things like source file naming, code
formatting, or bug report number for change tracking. Eclipse should enable
tools that help achieve that integrity and consistency. Eclipse should provide
more access points so that complex policies can be suggested, checked, or
enforced. [Platform Core; Team] (<a href="">71126</a>) [Theme: Large-scale development]<br>
<strong>Large-scale workspaces.</strong> Some
large customers have workspaces containing several hundred projects. Scoped
builds (added in 3.0) were a step in the right direction towards making these
workable. Eclipse needs to provide appropriate support for large workspaces
and working sets, and ensure that everything
scales properly. [Platform Core; Platform UI] (<a href="">71128</a>) [Theme: Large-scale development]</p>
<h4>Deferred Items (Eclipse Platform project)</h4>
<p><i>None at this time.</i></p>
<p>(End of items for Eclipse Platform project.)
<h2><a name="JDT">Java development tools (JDT) project</a></h2>
<p><a href="">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.</p>
<h4>Committed Items (Eclipse JDT project,)</h4>
<b>Add support for J2SE 5 features. </b>J2SE 5 (also known as JDK 1.5
&quot;Tiger&quot;) is targeted to ship in the second half of 2004. This
release contains <a href="">new Java
language features</a>, including generic types, typesafe enumerations,
autoboxing, enhanced for loops, static imports, varargs, and annotations.
Supporting these new language and compiler features requires major changes to
the Eclipse Java compiler, to JDT Core APIs, to JDT UI, and to JDT Debug. Eclipse should
contain full support for developing Java programs that use the new language
features, including code assist, quick fixes, new wizards, source actions, and refactorings. [JDT Core, JDT
UI, JDT Text, JDT Debug] (<a href="">36938</a>)
[Theme: J2SE 5 support] [Note:
Since the code for Eclipse 3.1 will be based on J2SE 1.4, we will be unable to
&quot;eat our own dog food&quot; in regards to the new J2SE 5 features. This means we'll
need to consider how best to achieve high quality. For instance, we might want
to develop an example plug-in written using J2SE 5 features.]</blockquote>
<h4>Proposed Items (Eclipse JDT project)</h4>
<b>Improve program manipulation infrastructure.</b> Parts of the Java
model are still implemented in terms of the deprecated JDOM, an early
precursor of the AST facility. JDT should move to an AST-based implementation
of the Java model. All source and refactoring operations should be rewritten to use common program
manipulation infrastructure based on ASTs and AST rewriting. AST creation in the presence of syntax
errors should be improved to include partial bindings for the code that lexically precede the syntax error. The performance of AST creation should be improved by using a
special parser and eliminating one internal layer of ASTs. There should also be better support for navigating between
a node in an AST (or an AST binding) and the corresponding element in the Java model
(which would benefit views that present type hierarchies). [JDT Core, JDT UI]
(<a href="">71129</a>)
[Theme: Built to last]<br>
<b>Snippet-based searching.</b> Allow search patterns to contain
code snippets that are to be further matched against the occurrence. For example allow
searching for all method calls to IRunnableContext#run where the first
argument is boolean 'false'. [JDT Core, JDT UI] (<a href="">71130</a>)
[Theme: none]
<h4>Deferred Items (Eclipse JDT project)</h4>
<p><i>None at this time.</i></p>
<p>(End of items for Eclipse JDT project.)
<h2><a name="PDE">Plug-in development environment (PDE) project</a></h2>
The <a href="">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 project)</h4>
<p><i>None at this time.</i></p>
<h4>Proposed Items (Eclipse PDE project)</h4>
<b>RCP support.</b> PDE currently supports developing Eclipse plug-ins, but is
not expressly geared for the specific needs of clients developing applications
based on the RCP. PDE should facilitate developing and deploying RCP-based
applications. (<a href="">71131</a>) [Theme: RCP]
<h4>Deferred Items (Eclipse PDE project)</h4>
<p><i>None at this time.</i></p>
<p>(End of items for Eclipse PDE project.)