Google Git
Sign in
eclipse / www.eclipse.org / eclipse / refs/tags/R4_3 / . / development / eclipse_project_plan_3_2_20051109.html
blob: 9598bb4acfc02bc2d1991a76508408ab0e89c2ae [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="Author" content="Eclipse Platform PMC">
<title>Eclipse Platform Project Draft 3.2 Plan</title><link rel="stylesheet" href="../../default_style.css" type="text/css"></head>
<body>
<h1>The Eclipse Project DRAFT 3.2 Plan</h1>
<p>Last revised 14:00 EST Nov. 9, 2005 (<img src="new.gif" alt="(new)" border="0" height="12" width="12">
marks interesting changes since the previous <a href="eclipse_project_plan_3_2_20050805.html">draft
of Aug. 5, 2005</a>)</p>
<p> <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 the Eclipse SDK after 3.1, designated release 3.2.
</p><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 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><li><a href="#Equinox"><img src="new.gif" alt="(new)" border="0" height="12" width="12"> Equinox project</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 Project PMC) post plans in an embryonic form and revise them
throughout the release cycle.
</p><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><p>The remainder of the plan consists of plan items for the <img src="new.gif" alt="(new)" border="0" height="12" width="12"> four projects under
the top level Eclipse Project. Each plan item covers a feature or API
that is to be added to the Eclipse Project deliverables, or some aspect of the Eclipse Project
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><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 component; others may involve coordinated changes to
several components; other may pervade the entire SDK. Although some plan
items are for work that is more pressing than others, the plan items appear in
no particular order.
</p><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><p>The current status of each plan item is noted:
</p><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 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>
</ul>
<h2><a name="Deliverables"></a>Release deliverables</h2>
<p>The release deliverables have the same form as previous releases, namely:
</p><ul>
<li>Source code release for all Eclipse Project deliverables, available as versions
tagged "R3_2" in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS
repository</a>.</li>
<li>Eclipse SDK (runtime binary and SDK for Platform,
JDT, and PDE) (downloadable).</li>
<li>Eclipse Platform (runtime binary and SDK for the Platform only) (downloadable).</li>
<li>Eclipse RCP (runtime binary and SDK for the Rich Client Platform) (downloadable).</li>
<li>Eclipse JDT (runtime binary and SDK for the Java Development Tools) (downloadable).</li>
<li>Eclipse PDE (runtime binary and SDK for the Plug-in Development Environment) (downloadable).</li>
<li>Eclipse SDK Examples (downloadable).</li>
<li>SWT distribution (downloadable).</li><li><img src="new.gif" alt="(new)" border="0" height="12" width="12"> Equinox OSGi R4 framework and assorted service implementations (downloadable).</li>
</ul>
<h2><a name="Milestones"></a>Release milestones</h2>
<p>Release milestones, occurring at roughly 6 week intervals, exist to facilitate
coarse-grained planning and staging. The milestones are:</p>
<ul>
<li> Friday Aug. 12, 2005 - Milestone 1 (3.2 M1) - stable build</li>
<li> Friday Sep. 23, 2005 - Milestone 2 (3.2 M2) - stable build</li>
<li> Friday Nov. 4, 2005 - Milestone 3 (3.2 M3) - stable build</li>
<li> Friday Dec. 16, 2005 - Milestone 4 (3.2 M4) - stable build</li>
<li> <img src="new.gif" alt="(new)" border="0" height="12" width="12"> Friday
Feb. 17, 2006 - Milestone 5 (3.2 M5) - stable build - API complete - API freeze</li>
<li> <img src="new.gif" alt="(new)" border="0" height="12" width="12"> Friday
Mar. 31, 2006 - Milestone 6 (3.2 M6) - stable build - feature complete - development
freeze - lock down and testing begins</li>
</ul>
<p>Our target is to complete 3.2 in <img src="new.gif" alt="(new)" border="0" height="12" width="12">
late June 2006. 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
operating environments.&nbsp;</p>
<p>Most of the Eclipse SDK is "pure" Java code and has no
direct dependence on the underlying operating system. The chief dependence is
therefore on the Java Platform itself. Portions
of the Eclipse SDK (including the RCP base, SWT, OSGi and JDT core
plug-ins) are targeted to specific classes of operating environments,
requiring their source code to only reference facilities available in
particular class libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4,
etc.).&nbsp; Some features planned for the SDK (such as Annotation
Processing support) require Java SE 5, and as such the 3.2 release of
the Eclipse SDK as a whole is developed against version 1.5 of the Java
Platform (i.e., Java SE 5). <img src="new.gif" alt="(new)" border="0" height="12" width="12">
<a href="#Appendix1">Appendix 1</a> contains a table that indicates the class library level required
for each plug-in.</p>
<p><img src="new.gif" alt="(new)" border="0" height="12" width="12">
<i>Note:</i>
As of the current revision date of this plan, there is some question as
to whether Java SE 5 VMs will be available with sufficient quality, on
a sufficiently wide range of platforms, early enough for us to be able
to commit to developing code that makes use of the new features these
VMs provide, in the 3.2 timeframe. As a result of this, the plan to use
Java SE 5 as a basis for 3.2 may have to be reconsidered. If this does
occur, the plan will be revised to reflect the change. </p>
<p>There are many different implementations of the Java Platform running atop
a variety of operating systems. We focus Eclipse SDK testing on a handful
of popular <span class="header">combinations of operating system and Java 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 a 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>The Eclipse SDK 3.2 is tested and validated on the following reference
platforms (this list is updated over the course of the release cycle):</p>
<table summary="Eclipse Reference Platforms" border="1" width="821">
<tbody><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 Standard Edition 5.0 Update 4 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
5.0</p>
</td>
</tr>
<tr>
<td height="22" width="205"> Red Hat Enterprise Linux WS 4</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453"> Sun Java 2 Standard Edition 5.0 Update 4 for Linux x86</td>
</tr>
<tr>
<td width="205"> Red Hat Enterprise Linux WS 4</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 5.0</td>
</tr>
<tr>
<td width="205">SLES 9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453"> Sun Java 2 Standard Edition 5.0 Update 4 for Linux x86</td>
</tr>
<tr>
<td width="205">SLES 9</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 5.0</td>
</tr>
<tr>
<td width="205"> Sun Solaris 10</td>
<td width="76">SPARC</td>
<td width="59">Motif</td>
<td width="453"> Sun Java 2 Standard Edition 5.0 Update 2 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"><p> HP-UX JDK for the Java 2 Platform Standard Edition for
5.0 01</p>
</td>
</tr>
<tr>
<td height="21" width="205">IBM AIX 5L Version 5.2</td>
<td width="76">Power</td>
<td width="59">Motif</td>
<td width="453"> <p> IBM 32-bit SDK for AIX, Java 2 Technology Edition 5.0</p>
</td>
</tr>
<tr>
<td width="205"> Apple Mac OS X 10.4</td>
<td width="76">Power</td>
<td width="59">Carbon</td>
<td width="453"> Java 2 Platform Standard Edition (J2SE) 5.0 Release 1 for
Tiger</td>
</tr>
<tr>
<td width="205"> <img src="new.gif" alt="(new)" border="0" height="12" width="12">
Red Hat Enterprise Linux WS 4</td>
<td width="76"><img src="new.gif" alt="(new)" border="0" height="12" width="12">
Power</td>
<td width="59"><img src="new.gif" alt="(new)" border="0" height="12" width="12">
GTK</td>
<td width="453"> <img src="new.gif" alt="(new)" border="0" height="12" width="12">
IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition
5.0</td>
</tr>
<tr>
<td width="205"><img src="new.gif" alt="(new)" border="0" height="12" width="12">
SLES 9</td>
<td width="76"><img src="new.gif" alt="(new)" border="0" height="12" width="12">
Power</td>
<td width="59"><img src="new.gif" alt="(new)" border="0" height="12" width="12">
GTK</td>
<td width="453"> <img src="new.gif" alt="(new)" border="0" height="12" width="12">
IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition
5.0</td>
</tr>
</tbody></table>
<p>Although untested, the Eclipse SDK 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 libraries
(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 the Eclipse SDK is also available for 64-bit
Linux GTK. Testing has been limited to early access 64-bit J2SEs running on
x86-64 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.2 on Windows or Linux
can be used to cross-develop QNX applications. (Eclipse 3.2 is unavailable on QNX
because there is currently no 1.5 J2SE for QNX.)</p>
<h4>Internationalization</h4>
<p>The Eclipse SDK 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><p>The Eclipse SDK supports GB 18030 (level 1), the Chinese code page
standard, on Windows XP and 2000, and Linux/GTK.
</p><p>German and Japanese locales are tested.</p>
<h4>BIDI support</h4>
<p>SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering
and displaying BIDI text. Within these limitations, the Eclipse
SDK tools are BIDI enabled.</p>
<h2><a name="Compatibility"></a>Compatibility with Previous Releases</h2>
<h3>Compatibility of Release 3.2 with 3.1</h3>
<p>Eclipse 3.2 will be compatible with Eclipse 3.1 (and, hence, with 3.0).</p>
<p><b>API Contract Compatibility:</b> Eclipse SDK 3.2 will be upwards contract-compatible
with Eclipse SDK 3.1 except in those areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.platform.doc.isv/porting/eclipse_3_2_porting_guide.html" target="_top"><em>Eclipse
3.2 Plug-in Migration Guide</em></a>. Programs that use affected APIs and extension
points will need to be ported to Eclipse SDK 3.2 APIs. Downward contract compatibility
is not supported. There is no guarantee that compliance with Eclipse SDK 3.2
APIs would ensure compliance with Eclipse SDK 3.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.2 will be upwards binary-compatible
with Eclipse SDK 3.1 except in those areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.platform.doc.isv/porting/eclipse_3_2_porting_guide.html" target="_top"><em>Eclipse
3.2 Plug-in Migration Guide</em></a>. Downward plug-in compatibility is not
supported. Plug-ins for Eclipse SDK 3.2 will not be usable in Eclipse SDK 3.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><p><b>Source Compatibility:</b> Eclipse SDK 3.2 will be upwards source-compatible
with Eclipse SDK 3.1 except in the areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.platform.doc.isv/porting/eclipse_3_2_porting_guide.html" target="_top"><em>Eclipse
3.2 Plug-in Migration Guide</em></a>. This means that source files written to
use Eclipse SDK 3.1 APIs might successfully compile and run against Eclipse
SDK 3.2 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><p><b>Workspace Compatibility:</b> Eclipse SDK 3.2 will be upwards workspace-compatible
with Eclipse SDK 3.1 unless noted. This means that workspaces and projects created
with Eclipse SDK 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.2 and
upgraded to a 3.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 3.2 should provide similar upwards compatibility for their hidden and visible
workspace metadata created by earlier versions; 3.2 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.2 will be unusable
with a product based an earlier version of Eclipse. Visible metadata files created
(or overwritten) by Eclipse 3.2 will generally be unusable with earlier versions
of Eclipse.
</p><p><b>Non-compliant usage of API's</b>: All non-API methods and classes, and
certainly everything in a package with "internal" 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 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.
</p><h2>Themes and Priorities</h2>
<p>The changes under consideration for the next release of Eclipse
Platform, JDT, PDE and Equinox will address major themes identified by
the Eclipse Requirements Council (Themes and Priorities dated Dec. 15,
2004 - <a href="http://www.eclipse.org/org/councils/20041215EclipseTPFinalDraft.pdf">pdf)</a>.
The following are especially germane to this top level project:</p>
<ul>
<li><strong>Scaling Up</strong> - This refers to the need for Eclipse to deal
with development and deployment on a larger and more complex scale. Increasing
complexities arise from large development teams distributed in different locations,
large source code bases and fragile build environments that have been developed
incrementally over time, the dynamic nature of new source code bases and their
interaction with configuration management, and build environments involving
many different tools and build rules.</li>
<li><strong>Enterprise Ready</strong> - Eclipse should be improved to allow
it to be better used by large development organizations.</li>
<li><strong>Design for Extensibility: Be a Better Platform</strong> - Within
the Eclipse community, many development projects are defining new development
platforms on top of the Eclipse Project deliverables. These must evolve
to better support this type of usage, including providing new common infrastructure
and abstraction layers needed by upper platforms and adding APIs to expose
existing functionality only available internally so that upper platforms can
more readily integrate with and reuse what's already there.</li>
<li><strong>Simple to Use</strong> -
The Eclipse components need to not only provide the features that advanced users demand,
but also be something that most users find simple to use.</li>
<li><strong>Rich Client Platform</strong> -
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.</li>
<li><strong>Appealing to the Broader Community</strong> -
This theme includes work that grows deeper roots into the various OS-specific communities,
spreads Eclipse to additional operating environments, virtual machines, application
development and deployment lifecycles, vertical market-specific frameworks and builds
bridges to other open source communities.</li>
</ul>
<p>Each of the four projects under the top-level Eclipse Project is covered
in its own section: </p>
<ul>
<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><li><a href="#Equinox">Equinox project</a></li>
</ul>
<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.
</p><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>
<h4>Committed Items (Eclipse Platform project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse Platform project)</h4>
<blockquote>
<p><strong>Support logical model integration.</strong> The Eclipse Platform
supports a strong physical view of projects containing resources (files and
folders) in the workspace. However, there are many situations where plug-in
developers would prefer to work with a logical model that is appropriate to
their domain. Eclipse should ease the task for plug-in developers who want
to make logical model-aware plug-ins. To do this, Eclipse should provide more
flexible mechanisms for contributing actions on models that do not have a
one-to-one mapping to files on the users hard disk. This would, for example,
allow a team provider's repository operations to be made available on logical
artifacts. In addition, existing views like the navigator and problems view
should be generalized to handle logical artifacts and, in general, there should
be better control over what is displayed in views and editors based on the
logical models that the end user is working on. [Resources, UI, Team]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">37723</a>)
[Theme: Design for Extensibility]</p>
<p><strong>Provide more flexible workspaces.</strong> Currently in Eclipse there
is a direct connection between IResources and files and directories on the
local file system. Eclipse should loosen this connection, by abstracting out
its dependency on java.io.File, and allowing for alternative implementations.
This would enable, for example, uses where the workspace is located on a remote
server, or accessed via a non-file-based API, or has a non-trivial mapping
between the resources and the physical layout of the files. [Resources,
Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106176">106176</a>)
[Theme: Design for Extensibility, Enterprise Ready]</p>
<p><strong>Improve and extend the SWT widget set.</strong> Modern UI design
is a constantly moving target. SWT should provide the tools needed to implement
first class user interfaces. For example: sort indicators in SWT tables; improved
coolbar behavior/appearance; and new controls such as collapsible groups.
[SWT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106182">106182</a>)
[Theme: Design for Extensibility, Appealing to the Broader Community]</p>
<p><strong>Address new window system capabilities.</strong> SWT's basis in native
widgets is one of Eclipse's major strengths. For this to remain true, SWT
must continue to grow to encompass new mainstream desktop platforms and new
capabilities added to existing platforms. SWT should support Windows Vista,
and handle the GB18030-2 Chinese character set where it is supported natively.
[SWT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106184">106184</a>)
[Theme: Appealing to the Broader Community]</p>
<p><strong>Update Enhancements.</strong> As the number and range of Eclipse
plug-ins continues to grow, it becomes increasingly important to have a powerful
update/install story. For instance, if more information about an Eclipse install
was available earlier, it would be possible to pre-validate that it would
be a compatible location to install particular new features and plug-ins.
This information could also be used to deal with conflicting contributions.
Update should also be improved to reduce the volume of data that is transferred
for a given update, and PDE should provide better tools for creating and deploying
updates. [Update, Runtime, PDE] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106185">106185</a>)
[Theme: Enterprise Ready]</p>
<p><strong>Increase flexibility when building RCP applications.</strong> The Eclipse
text editor should better support RCP applications, by making features like
the following available to them: annotation presentation and navigation, user
assigned colors and fonts, spell checking, folding, quick diff, templates,
and file buffers. The Eclipse workbench layout should be further opened up
to allow RCP applications to have more control over its presentation. [Text, UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106187">106187</a>)
[Theme: Rich Client Platform]</p><p><strong>Provide a more customizable UI.</strong>
Products often need direct control over the presence and arrangement of
UI elements. Similarly, end users expect to be able to customize the UI
to better match their workflow. Eclipse should enable both products and
end users to have more control over the user interface. For example,
the workbench layout should be made more flexible and configurable, and
there should be a framework to allow better control over the presence
and ordering of menu and toolbar items. [UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106189">106189</a>)
[Theme: Simple to Use]</p>
<p><strong>Capabilities/Perspectives/Components.</strong> The UI component has
several frameworks for customizing the presentation, filtering the set of
available options and supporting task-based UIs tailored to the user's role.
This support should be rationalized and better documented. [UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80130">80130</a>)
[Theme: Simple to Use]</p>
<p><strong>Provide more support for large scale workspaces.</strong> In some
situations, users have workspaces containing hundreds of projects and hundreds
of thousands of files. Scoped builds and working sets have become important
tools for these users, and the performance optimizations done in Eclipse 3.1
have proven helpful. Eclipse should have even more support for dealing with
very large workspaces, including improved searching, filtering, working sets,
and bookmarks. This goes hand-in-hand with ongoing work to discover and address
performance issues. [UI, Resources] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106192">106192</a>)
[Theme: Scaling Up, Enterprise Ready]</p>
<p><strong>Improve serviceability.</strong> When an end user encounters a problem
with Eclipse, it is important for support teams to be able to diagnose the
root cause of the failure, and identify the failing plug-in. Eclipse should
have enhanced error reporting tools that make it easy for end users to report
problems. Tools should be available at all times, so that knowledgeable users
could diagnose unexpected behavior such as slowdowns or exceptional memory
use. [Runtime,&nbsp;UI, SWT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106193">106193</a>)
[Theme: Simple to Use, Enterprise Ready]</p><p><strong>Enhance the text editor.</strong> The Eclipse Text component provides
a powerful editing framework that is useful in many contexts, but some of
its capabilities are currently only available in the Java editor. The Java
editor should be opened up to allow more general access to the reconciling,
code assist, and template proposal mechanisms. Other enhancements to the look
and feel of the editor should also be considered in areas such as the Find/Replace
dialog, showing change history and comments in the editor, and annotation
roll-overs. [Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106194">106194</a>)
[Theme: Design for Extensibility]
</p><p><strong>Improve cheat sheet support.</strong> The Eclipse cheat sheet infrastructure
was implemented 3.0, but is still not widely used. For cheat sheets to be
become more widely adopted, the base support should be enhanced in several
ways, including: allowing cheat sheets to be authored by non-developers (i.e.
creating steps and registering a cheat sheet with no programming); defining
and using new automation APIs to allow UI parts like dialogs and wizards to
be opened and filled in; and enhancing the implementation to support working with modal dialogs. [UA, UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106196">106196</a>)
[Theme: Simple to Use, Design for Extensibility]</p>
<p><strong>Provide pervasive user-assistance search capabilities.</strong> An
important element of the user-assistance support in Eclipse is the federated
help search support that was added in R3.1. This support should be expanded
to pull in more useful results from various sources. It should also be made
more extensible to assist other information contributors, and made more pervasive
in the UI. [UA] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106198">106198</a>)
[Theme: Simple to Use]</p>
<p><strong>Improve task assistance in text fields.</strong> Eclipse has numerous
wizards and dialogs that contain text fields where there are constraints on
the values that can be entered, and often task assistance can be provided,
for example, in the form of potential values. Eclipse should provide an enhanced
text field that has indicators for required fields, and content assist. [UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106199">106199</a>)
[Theme: Simple to Use]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> name changed)
<strong>Support dynamic and reusable content in User Assistance components.</strong>
In previous releases, Eclipse Help manipulated content as a reference. Although
the representation is simple and reliable, it is difficult to tailor the content
for multiple presentations, or to provide incremental content contributions,
content reuse, content filtering etc. The representation for help content
should be improved. Also, branding information should be separated from the
rest of the content to simplify aggregating multiple contributions into larger
units. These features also apply to Welcome, CheatSheets and the dynamic help
view. [UA] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106201">106201</a>)
[Theme: Design for Extensibility]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new) <b>Help
System enhancements.</b> Enhance the existing Help System functionality in
several ways, including support for navigation bread crumbs, support for remote
installation of Help documentation, documentation index, more extensible dynamic
help view, and various other enhancements. [UA] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=114243">114243)</a>
[Theme: Design for Extensibility]</p>
<p><strong>Improve UI Forms.</strong> UI Forms are increasingly being used in
the Eclipse user interface. The UI Form support should be improved to allow
for more pervasive use in 3.2. Critical widget functionality should be moved
to SWT to ensure quality and native look and feel. The remaining UI Forms
code (minus FormEditor) should be pushed down into JFace so that it is available
in the Eclipse workbench. [SWT, UI, UA] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106203">106203</a>)
[Theme: Simple to Use, Design for Extensibility]</p>
<p><strong>Enhance the debug platform.</strong> The debug support in Eclipse
is increasingly being used in areas that require more flexible mechanisms
than those required by simple Java programs. Potential work areas include:
the integration of flow control, async/cancellation into debug APIs; update
policies in debug views (i.e. ensure view updates before proceeding vs. let
debugger go as fast as it can and let the views catch up); a flexible debug
model element hierarchy to account for different architectures such as multi-core
processors, thousands of threads, etc; and introduction of table trees in
standard debug views for better/flexible presentation. [Debug] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106205">106205</a>)
[Theme: Design for Extensibility, Enterprise Ready]</p>
</blockquote>
<h4>Deferred Items (Eclipse Platform project)</h4>
<blockquote>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Embedding editors and views.</strong> Various problems are encountered
when trying to embed editors or views within other workbench parts. For example,
the current compare infrastructure requires creating a separate text editor
for viewing changes between files. This is due to a limitation in the workbench
that prevents editors from being embedded inside views or other controls.
As a consequence, the compare editor's nested editors don't support the full
set of features provided by the corresponding real content-type-specific editor.
This represents a major usability problem: the user must switch to the real
editor to make changes and then return to the compare view to review the changes.
Eclipse should be more flexible in the ways various editors can be used and
reused. The UI component model should be improved to support nesting of workbench
parts, and reduce the coupling of parts to particular locations in the workbench,
allowing for more flexible UI configurations. [UI, Compare, Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71125">71125</a>)
[Theme: Design for Extensibility]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Provide a single user-assistance content delivery mechanism.</strong>
In Eclipse 3.1, three different user-assistance vehicles are used to help
users in various contexts: the initial user experience shows the 'Welcome'
content; cheat sheets assist during long tasks; Help shows the traditional
help topics. These vehicles use similar concepts but have separate/duplicate
code bases. They should be reworked so that a single content delivery mechanism
is used in various contexts, allowing content producers to benefit from a
single way of contributing content, making all the content searchable, and
making it presentable in various contexts. This should also take into account
whether content is local or remote. [UA] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106200">106200</a>)
[Theme: Design for Extensibility]</p>
<strong></strong><strong></strong>
</blockquote>
<p>(End of items for Eclipse Platform project.)</p>
<h2><a name="JDT">Java development tools (JDT) project</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.</p>
<h4>Committed Items (Eclipse JDT project,)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse JDT project)</h4>
<blockquote>
<p><strong>Add support for Java SE 6 features.</strong> Java SE 6 (aka "Mustang")
will likely contain improvements to javadoc tags (like @category), classfile
specification updates, pluggable annotation processing APIs, and new compiler
APIs, all of which will require specific support. [JDT Core, JDT UI, JDT Text,
JDT Debug] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106206">106206</a>)
[Theme: Appealing to the Broader Community]</p>
<p><strong>Improve refactoring.</strong> Refactoring currently relies on a closed
world assumption. This means that all of the code to be refactored must be
available in the workspace when the refactoring is triggered. However for
large distributed teams, the closed world approach isn't really feasible.
The same is true for clients which use binary versions of libraries where
API changes from one version to another. In 3.2 the closed world assumptions
will be relaxed in such a way that a refactoring executed in workspace A can
be "reapplied" on workspace B to refactor any remaining references to the
refactored element. Furthermore, existing refactorings will be improved to
preserve API compatibility where possible (for example when renaming a method,
a deprecated stub with the old signature will be generated that forwards to
the new method). [JDT Core/UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106207">106207</a>)
[Theme: Scaling Up].</p>
<p><strong>Implement library projects.</strong> For plug-in development, PDE
distinguishes between the plug-in projects you are working on (source plug-in
projects) and plug-in projects you are working with but not actually changing
(binary plug-in projects). Making this distinction affords the user the benefits
of having full source for everything in their workspace where it's easily
browsed and searched, while permitting economies because the latter kind of
projects do not actually have to be (re)compiled. This work item is to support
a similar notion of library project for Java development in general. The user
should be able to flag a Java project as a library project; JDT would then
know how to present library projects appropriately at the UI, and how to deal
with them more efficiently using generated binaries. [JDT Core, JDT UI, PDE]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80162">80162</a>)
[Theme: Design for Extensibility]</p>
<p><strong>Improve NLS tooling.</strong> The Eclipse NLS tooling should better
support the new Eclipse string externalization pattern added in 3.1, along
with ways to help developers with unused keys and unused property file entries.
[JDT Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106210">106210</a>)
[Theme: Simple to use, Scaling up]</p>
</blockquote>
<h4>Deferred Items (Eclipse JDT project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse JDT project.)
</p><h2><a name="PDE">Plug-in development environment (PDE) project</a></h2>
The <a href="http://www.eclipse.org/pde/index.html">plug-in development
environment</a> (PDE) consists of 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>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse PDE project)</h4>
<blockquote>
<p><strong>Improve target support.</strong> PDE manages a model of the target
Eclipse for which you are developing. Targets may be complex and diverse,
and switching targets or launch configurations can be expensive. PDE should
be extended to support named targets and automatically track changes to the
workspace. [PDE, Runtime] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106211">106211</a>)
[Theme: Simple to Use, Enterprise Ready]</p>
<p><strong>New source lookup for debugging Eclipse applications.</strong> The
default source lookup mechanism for debugging Java applications has scalability
issues since the debugger may needing to scan a list of hundreds of plug-in
projects each time it look up a source file. PDE should provide its own source
path computer to which the debugger can delegate the task of locating source
files. In addition to faster lookups, the PDE-based approach will be better
positioned to handle duplicate source files on the same source path. It would
also allow the user to easily debug plug-ins against different targets without
having to change the Target Platform in the preferences. [PDE, Debug, Runtime]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106212">106212</a>)
[Theme: Scaling Up]</p>
<p><strong>API-aware tools.</strong> Given the importance that the Eclipse community
places on stable, robust APIs, having good support for their implementation
is critical. The support within Eclipse for describing APIs should be improved,
along with better tools from assisting developers to stick to APIs provided
by other plug-ins. [PDE, JDT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106213">106213</a>)
[Theme: Enterprise Ready]</p>
<p><strong>Improve PDE build.</strong> PDE Build is fundamental to how the Eclipse
Platform releases are produced. It is also increasingly being used by other
Eclipse projects and in the wider community. Potential improvements to PDE
build include parallel cross-building, incremental building of plug-ins, increased
integration with the workspace model, and support for additional repository
providers. [PDE] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106214">106214</a>)
106214[Theme: Enterprise Ready]</p>
</blockquote>
<h4>Deferred Items (Eclipse PDE project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>(End of items for Eclipse PDE project.)</h4><h2><a name="Equinox">Equinox project</a></h2>The <a href="http://www.eclipse.org/equinox/index.html">Equinox</a>
project provides an implementation of the OSGi R4 core framework
specification, a set of bundles that implement various optional OSGi
services and other infrastructure for running OSGi-based systems. The
following work items reflect new features of Equinox, or areas where
existing features will be significantly reworked.
<h4>Committed Items (Equinox project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Equinox project)</h4>
<blockquote>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> moved
from Platform) <strong>Give OSGi a first class presence on eclipse.org.</strong>
Eclipse is based on an efficient, highly scalable OSGi implementation, which
has always been usable as a standalone component. OSGi should have a first
class presence on eclipse.org, including making it easy for developers to
reuse the Eclipse OSGi implementation in their own applications. To support
this, a separate OSGi download should be provided, as is done for SWT. [Runtime]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106188">106188</a>)
[Theme: Appealing to the Broader Community, Rich Client Platform]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new) <b>Refactor
the runtime.</b>&nbsp;The Eclipse runtime is currently one monolithic plugin
that contains the extension registry, jobs, preferences, content types, application
model and various helper/utility classes.&nbsp; Various use cases demand independent
use of these facilities.&nbsp; The runtime should be refactored into individual
bundles for the different functional areas to improve the support for specific
use cases such as using the extension registy on standard OSGi systems or
standalone, and better integration between the Eclipse application model and
OSGi (e.g., the OSGi MEG application model). [Framework, Bundles, Runtime]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=113663">113663</a>)
[Theme: Appealing to the Broader Community, Rich Client Platform]</p>
<strong></strong></blockquote>
<h4>Deferred Items (Equinox project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>(End of items for Equinox project.)</h4>
<h2><img src="new.gif" alt="(new)" border="0" height="12" width="12"><a name="Appendix1">Appendix 1: Execution Environment by Plug-in</a></h2>
<p>In the table below, the "3.2 EE" ("3.2 Execution Environment") column indicates
the minimum Java class library requirements of each plug-in for the 3.2 release,
where the value is one of:</p>
<table border="0" width="90%">
<tbody><tr><td align="center"><b>Entry</b></td><td align="left"><b>Meaning</b></td></tr><tr>
<td><div align="center"><strong>M1.0</strong></div>
</td>
<td>OSGi Minimum Execution Environment 1.0 - This is a subset of the J2ME
Foundation class libraries defined by OSGi to be the base for framework
implementations. See the OSGi specifation for more details.</td>
</tr>
<tr>
<td width="9%"><div align="center"><strong>M1.1</strong></div></td>
<td width="91%">OSGi Minimum Execution Environment 1.1 - This is a subset
of the J2ME Foundation class libraries defined by OSGi to be the base
for framework implementations. See the OSGi specifation for more details.</td>
</tr>
<tr>
<td><div align="center"><strong>F1.0</strong></div>
</td>
<td>J2ME Foundation 1.0 - indicates that the plug-in can only be run on
Foundation 1.0 or greater. Note that with the exception of some MicroEdition
IO classes, Foundation 1.0 is a subset of J2SE 1.2.</td>
</tr>
<tr>
<td><div align="center"><strong>F1.1</strong></div></td>
<td>J2ME Foundation 1.1 - indicates that the plug-in can only be run on
Foundation 1.1 or greater. Note that with the exception of some MicroEdition
IO classes, Foundation 1.1 is a subset of J2SE 1.3.</td>
</tr>
<tr>
<td><div align="center"><strong>1.2</strong></div></td>
<td>J2SE 1.2 - indicates that the plug-in can only be run on JSE 1.2 or
greater.</td>
</tr>
<tr>
<td><div align="center"><strong>1.3</strong></div></td>
<td>J2SE 1.3 - indicates that the plug-in can only be run on JSE 1.3 or
greater.</td>
</tr>
<tr>
<td><div align="center"><strong>1.4</strong></div></td>
<td>J2SE 1.4 - indicates that the plug-in can only be run on JSE 1.4 or
greater.</td>
</tr><tr><td align="center"><b>n/a</b></td>
<td>Unknown at the time of this revision.</td>
</tr>
</tbody></table><br><b>Table of minimum execution environments by plug-in.</b><br><br><table border="1">
<tbody><tr>
<td width="290"><strong>Plug-in</strong></td>
<td width="60"><div align="center"><strong>3.2 EE</strong></div></td>
</tr>
<tr>
<td>org.apache.ant</td>
<td><div align="center">1.2</div>
</td>
</tr>
<tr>
<td>org.apache.lucene</td>
<td><div align="center">n/a</div>
</td>
</tr>
<tr>
<td>org.eclipse.ant.core</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ant.ui</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.compare</td>
<td><div align="center">n/a</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.boot</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.commands</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.core.expressions</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.core.filebuffers</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.core.filesystem</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.resources</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.core.resources.compatibility </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.runtime</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.core.runtime.compatibility</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.variables</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.debug.core</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.debug.ui</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.help</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.help.appserver</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.help.base</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.help.ui</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.help.webapp</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.jdt</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.core</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.debug</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.debug.ui</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.doc.isv</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.doc.user</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.junit</td>
<td><div align="center">1.5</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.junit.runtime</td>
<td><div align="center">1.5</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.launching</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.source</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.jdt.ui</td>
<td><div align="center">1.5</div></td>
</tr>
<tr>
<td>org.eclipse.jface</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.jface.text</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.ltk.core.refactoring</td>
<td><div align="center">1.4/1.5</div></td>
</tr>
<tr>
<td>org.eclipse.ltk.ui.refactoring</td>
<td><div align="center">1.4/1.5</div></td>
</tr>
<tr>
<td>org.eclipse.osgi (system.bundle)</td>
<td><div align="center">M1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.osgi.services</td>
<td><div align="center">M1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.osgi.util</td>
<td><div align="center">M1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.pde</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.pde.build</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.pde.core</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.pde.doc.user</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.pde.junit.runtime</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.pde.runtime</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.pde.source</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.pde.ui</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.platform</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.platform.doc.isv</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.platform.doc.user</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.platform.source</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.platform.source.*</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.rcp</td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.rcp.source</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.rcp.source.*</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.sdk</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.search</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.swt</td>
<td bgcolor="#ffffff"><div align="center">M1.0</div></td>
</tr>
<tr>
<td>org.eclipse.swt.*</td>
<td bgcolor="#ffffff"><div align="center">M1.0</div></td>
</tr>
<tr>
<td>org.eclipse.team.core</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.team.cvs.core</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.team.cvs.ssh</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.team.cvs.ssh2</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.team.cvs.ui</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.team.ui</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.text</td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.tomcat</td>
<td><div align="center">n/a</div></td>
</tr>
<tr>
<td>org.eclipse.ui </td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.ui.browser </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.cheatsheets </td>
<td><div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.console </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.editors </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.externaltools </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.forms </td>
<td><div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.ide</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.intro </td>
<td><div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.presentations.r21 </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.views </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.win32 </td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.workbench </td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.ui.workbench.compatibility </td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.ui.workbench.texteditor </td>
<td><div align="center">1.4</div></td>
</tr>
<tr>
<td>org.eclipse.update.configurator </td>
<td bgcolor="#ffffff"><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.update.core </td>
<td bgcolor="#ffffff"><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.update.core.linux</td>
<td bgcolor="#ffffff"><div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.update.core.win32 </td>
<td bgcolor="#ffffff"><div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.update.scheduler </td>
<td bgcolor="#ffffff"><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.eclipse.update.ui </td>
<td><div align="center">F1.0</div></td>
</tr>
<tr>
<td>org.junit (old)</td>
<td><div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.junit (JUnit4)</td>
<td><div align="center">1.5</div>
</td>
</tr>
<tr>
<td>startup.jar</td>
<td><div align="center">F1.0</div></td>
</tr>
</tbody></table>
</body></html>