Google Git
Sign in
eclipse / gerrit / www.eclipse.org / eclipse / 1c5adc67fdfc88aacf8721ea11f04b9dbd76bbac / . / development / eclipse_project_plan_3_3_20070330.html
blob: 5930a8db3b564ed520f1501d643dff904d03838d [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 Project PMC">
<title>The Eclipse Project DRAFT 3.3 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>
<h1>The Eclipse Project DRAFT 3.3 Plan</h1>
Last revised 16:00 EST Mar 30, 2007
(<img src="new.gif" alt="(new)" border="0" height="12" width="12">
marks interesting changes since the previous
<a href="eclipse_project_plan_3_3_20070223.html">draft of Feb 23, 2007</a>)
<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.2, designated release 3.3.
</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="#ThemesandPriorities">Themes and Priorities</a></li>
<li><a href="#WorkAreas">Work Areas</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.
</p>
<p>The remainder of the plan consists of plan items for all of the sub-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_3" in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS
repository</a>.</li>
<li>Eclipse SDK (runtime binary and SDK for Equinox, Platform, JDT, and PDE) (downloadable).</li>
<li>Eclipse Platform (runtime binary and SDK for the Equinox and 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>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> Thursday Aug. 10, 2006 - Milestone 1 (3.3 M1) - stable build</li>
<li> Friday Sep. 22, 2006 - Milestone 2 (3.3 M2) - stable build</li>
<li> Friday Nov. 3, 2006 - Milestone 3 (3.3 M3) - stable build</li>
<li> Friday Dec. 15, 2006 - Milestone 4 (3.3 M4) - stable build</li>
<li> Friday Feb. 9, 2007 - Milestone 5 (3.3 M5) - stable build</li>
<li> Friday Mar. 23, 2007 - Milestone 6 (3.3 M6) - stable build - API complete - API Freeze</li>
<li> Friday May 4, 2007 - Milestone 7 (3.3 M7) - stable build - feature complete - development
freeze - lock down and testing begins</li>
</ul>
<p>Our target is to complete 3.3 in late June 2007. 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.
</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.).
</p><p>
In general, the 3.3 release of the Eclipse Project is developed on a
mix of Java 1.4 and Java5 VMs. As such, the Eclipse Project SDK as
a whole is targeted at both 1.4 and Java5 VMs, with full functionality
available for 1.4 level development everywhere, and new Java5 specific
capabilities available when running on a Java5 VM. Similarly, in cases
where support has been added for Java6 specific features (e.g. JSR-199,
JSR-269, etc.) Java6 VMs are required.
</p><p>
<a href="#Appendix1">Appendix 1</a> contains a table that indicates
the class library level required for each plug-in.
</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 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, including
those using Java6 VMs. 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.</p>
<p>
The Eclipse SDK 3.3 is tested and validated on the following reference
platforms (this list is updated over the course of the release cycle):</p>
<center>
<table border="1" cellpadding="2" cellspacing="2" width="80%" summary="Eclipse Reference Platforms">
<tbody>
<tr align="center">
<td><b>Reference Platforms</b></td>
</tr>
<tr><td>
<b>Microsoft Windows Vista, x86-32, Win32</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Microsoft Windows</li>
<li>IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4 (see caveat below)</li>
<li>BEA JRockit 5.0, for Microsoft Windows</li>
</ul>
</td></tr>
<tr><td>
<b>Microsoft Windows XP, x86-32, Win32</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Microsoft Windows</li>
<li>IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4</li>
<li>BEA JRockit 5.0, for Microsoft Windows</li>
<li>Sun Java 2 Standard Edition 1.4.2_14 for Microsoft Windows</li>
<li>IBM 32-bit SDK for Windows, Java 2 Technology Edition 1.4.2 SR7</li>
<li>BEA JRockit 1.4.2, for Microsoft Windows</li>
</ul>
</td></tr>
<tr><td>
<b>Red Hat Enterprise Linux 4.0 update 2, x86-32, GTK</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Linux x86</li>
<li>IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR4</li>
<li>BEA JRockit 5.0, for Linux x86</li>
<li>Sun Java 2 Standard Edition 1.4.2_13 for Linux x86</li>
<li>IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 SR7</li>
<li>BEA JRockit 1.4.2, for Linux x86</li>
</ul>
</td></tr>
<tr><td>
<b>SUSE Linux Enterprise Server 10, x86-32, GTK</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Linux x86</li>
<li>IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR4</li>
</ul>
</td></tr>
<tr><td>
<b>Red Hat Enterprise Linux 4.0 update 2, x86-64, GTK</b> running:
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Linux x86_64</li>
</ul>
</td></tr>
<tr><td>
<b>Sun Solaris 10, SPARC, GTK</b> running:
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Solaris SPARC</li>
</ul>
</td></tr>
<tr><td>
<b>IBM AIX 5.3, Power, Motif 2.1</b> running:
<ul>
<li>IBM 32-bit SDK, Java 2 Technology Edition 5.0, SR4</li>
</ul>
</td></tr>
<tr><td>
<b>Red Hat Enterprise Linux 4.0 update 2, Power, GTK</b> running:
<ul>
<li>IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 7</li>
</ul>
</td></tr>
<tr><td>
<b>SUSE Linux Enterprise Server 10, Power, GTK</b> running:
<ul>
<li>IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 7</li>
</ul>
</td></tr>
<tr><td>
<b>Apple Mac OS X 10.4, Universal, Carbon</b> running:
<ul>
<li>Apple Java 2 Platform Standard Edition (J2SE) 5, service release 4 for Tiger</li>
</ul>
</td></tr>
</tbody>
</table>
</center>
<dl>
<dt><em>Caveat: Using IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4 on Vista</em></dt>
<dd>Although we expect this to be fixed in IBM Java5 SR5, there is currently a conflict between
the use of DirectDraw by the <strong>AWT</strong> libraries in IBM Java5 SR4 and
the Windows Vista "Aero" theme. Although the Eclipse SDK itself does not use these libraries
(and thus runs well on Windows Vista using that VM), other plug-ins that make use of the
conflicting AWT capabilities may cause the advanced features of Aero to be disabled. As a
workaround to avoid this problem, you can add <code>-Dsun.java2d.noddraw=true</code> to the
VM arguments when launching Eclipse, which will prevent the AWT libraries from using DirectDraw.
</dd>
</dl>
<p>Because Java 1.4.2 and Java5 based platforms are used for most Eclipse
development, those platforms are listed here. Although there are teams
doing some Java 6 based development we have not included specific Java6 VMs,
since they have not yet received the general level of testing we require.
<i>We expect that Eclipse will work fine on other current Java VMs
running on window systems supported by SWT, but can not flag these as reference
platforms without significant community support for testing them.</i></p>
<p>Similarly, although untested, the Eclipse SDK should work fine on other OSes that
support the same window system. For Win32: 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
Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.</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.3 on Windows or Linux
can be used to cross-develop QNX applications. (Eclipse 3.3 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.3 with 3.2</h3>
<p>Eclipse 3.3 will be compatible with Eclipse 3.2 (and, hence, with 3.1 and 3.0).</p>
<p>
<strong>API Contract Compatibility:</strong> Eclipse SDK 3.3 will be upwards contract-compatible
with Eclipse SDK 3.2 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_3_porting_guide.html" target="_top">
<em>Eclipse 3.3 Plug-in Migration Guide</em>
</a>.
Programs that use affected APIs and extension points will need to be ported to
Eclipse SDK 3.3 APIs. Downward contract compatibility is not supported.
There is no guarantee that compliance with Eclipse SDK 3.3
APIs would ensure compliance with Eclipse SDK 3.2 APIs. Refer to
<a href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs">
<em>Evolving Java-based APIs</em>
</a> for a discussion of the kinds of API changes that maintain
contract compatibility.
</p>
<p><strong>Binary (plug-in) Compatibility:</strong> Eclipse SDK 3.3 will be upwards binary-compatible
with Eclipse SDK 3.2 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_3_porting_guide.html" target="_top">
<em>Eclipse 3.3 Plug-in Migration Guide</em>
</a>.
Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.3
will not be usable in Eclipse SDK 3.2. Refer to
<a href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs">
<em>Evolving Java-based APIs</em>
</a> for a discussion of the kinds of API changes that maintain
binary compatibility.
</p>
<p><strong>Source Compatibility:</strong> Eclipse SDK 3.3 will be upwards source-compatible
with Eclipse SDK 3.2 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_3_porting_guide.html" target="_top">
<em>Eclipse 3.3 Plug-in Migration Guide</em>
</a>.
This means that source files written to
use Eclipse SDK 3.2 APIs might successfully compile and run against Eclipse
SDK 3.3 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><strong>Workspace Compatibility:</strong> Eclipse SDK 3.3 will be upwards workspace-compatible
with Eclipse SDK 3.2 unless noted. This means that workspaces and projects created
with Eclipse SDK 3.2, 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.3 and
upgraded to a 3.3 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.3 should provide similar upwards compatibility for their hidden and visible
workspace metadata created by earlier versions; 3.3 plug-in developers are responsible
for ensuring that their plug-ins recognize 3.2, 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.3 will be unusable
with a product based an earlier version of Eclipse. Visible metadata files created
(or overwritten) by Eclipse 3.3 will generally be unusable with earlier versions
of Eclipse.
</p>
<p><strong>Non-compliant usage of API's</strong>: 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
<a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">
<em>How to Use the Eclipse API</em>
</a> for information about how to write compliant plug-ins.
</p>
<h2><a name="ThemesandPriorities">Themes and Priorities</h2>
<p>
The PMC of the Eclipse Project has identified six major areas of work,
that will be the priorities for this development cycle. These areas will
address the major themes identified by the Eclipse Requirements Council
(<a href="http://www.eclipse.org/org/councils/roadmap_v2_0/themes_v2_0.php">Themes and Priorities v2.0</a>).
</p>
<h2><a name="WorkAreas">Work Areas</h2>
<p>
Although there are four projects under the top-level Eclipse Project, there
is a significant amount of commonality and shared effort between them.
In general, many plan items involve coordinated changes to multiple
components, and thus attempting to separate the items into
sections based on sub-project leads to artificial distinctions between
them (e.g. Platform Text vs. JDT Text, Platform Debug vs.
JDT Debug, etc.).
</p>
<p>
In order to provide the clearest focus for our development effort, we
have organized the items below into sections based on the work area they
are intended to address. Items that apply to multiple
work areas are categorized based on where the most effort is expected
to occur. In all cases, the items listed reflect new features of Eclipse
or areas where existing features will be significantly reworked. Numbers in
parentheses link to bugzilla problem reports where progress on that
item can be tracked and discussed.
</p>
<p>
The major work areas are:
</p>
<ul>
<li><a href="#Components">Components</a></li>
<li><a href="#Consumability">Consumability</a></li>
<li><a href="#Java">Java</a></li>
<li><a href="#Vista">Vista</a>
<li><a href="#UIEvolution">UI Evolution</a>
<li><a href="#API">API</a>
</ul>
<!-- Start of Sections by Work Area -->
<h2><a name="Components">Components</a></h2>
<p>
This work will enhance Eclipse's use of, and support for, software components,
covering everything from component programming models such as Declarative
Services, API tools, incremental building and fine-grained function delivery.
</p>
<h4>Committed Items (Components)</h4>
<blockquote>
<p><strong>Target Provisioning.</strong>
Currently, users wanting additional function supplied by others must
manually acquire and install these additional bundles in their target
platform. This process is tiresome and error-prone. As an extension
to the proposed provisioning work, we will add the ability to provision
targets directly from bundle repositories as well as from other locations
on the local machine.
[PDE]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154081">154081</a>)
</p>
<p><strong>Application Model.</strong>
The OSGi R4 MEG specification includes an application model that significantly
decouples the application from the rest of the system. The net result is OSGi
(and thus Eclipse) as a more flexible application container, for example allowing
multiple applications to run concurrently and improved lifecycle around the
application. These characteristics are important both to the manageability of
the system (e.g., simplifying and clarifying the shutdown process) but also to
various RCP scenarios such as Kiosk-mode and Application Container models.
In 3.3 we will implement and adopt the MEG application model.
[Equinox]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154084">154084</a>)
</p>
<p><strong>OSGi R4.1 Specification Work.</strong>
Much of the success Eclipse has enjoyed with OSGi comes from the fact that the
Eclipse community has played a very active role in the evolution of various
OSGi specifications. With increased interest in OSGi and Java modularity
(see JSR 277, JSR 291 and JSR 232) this participation has never been more important.
In addition to promoting Eclipse use-cases and the evolution of these standards
to benefit Eclipse, there are a number of gaps in the OSGi specifications that
Eclipse is currently filling in specific ways and should be addressed in R4.1.
For example the management of API in metadata (x-friends and x-internal),
integration techniques for third party and legacy code, in-place execution of
bundles, basic notions of data location, etc. The Equinox team will continue
their active participation in these specification processes and keep Eclipse
on the leading edge of Java componentization.
<em>(Note that originally this plan item referenced "OSGi R5" but the next version
of the spec is going to be called "R4.1" so we have updated the item accordingly.)</em>
[Equinox]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154085">154085</a>)
</p>
<p><strong>Server side support.</strong>
First it was tools, then it was applications, now server-side programmers are
waking up to the power of componentization delivered by Eclipse and OSGi.
In the 3.2 cycle an Equinox incubator was started to investigate the use of
Eclipse on the server. It started as a very modest servlet bridge allowing
Eclipse to run inside a servlet engine and handle servlet requests and has been
evolving into a full-blown appreciation of what it means to componentize server
software. There are many possible directions here and there is no way the
Equinox team proper will be able to track, support and participate in all.
However we will spend time understanding the basic requirements as they apply
to the base framework and add-on services and look to support the use-cases
presented by various other Eclipse projects that are adopting Eclipse on the
server (e.g., ECF, ECP, Corona).
[Equinox]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154087">154087</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> wording has changed)
<strong>Help content generated on-the-fly</strong>
Currently it is not possible to write all your help content in your own
format, and have it converted into HTML, TOC, keyword index, and context
help on-the-fly. For the table of contents you must supply the information
in the toc XML format, you cannot use any other format or write code to
contribute tocs. The same restriction exists with keyword index content.
This item consists of adding API for toc and keyword index providers,
and ensuring that a full end-to-end generated doc set is possible.
[UA]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175016">175016</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> wording has changed)
<strong>Improve componentization of user assistance content</strong>
More flexibility for filtering, such as OR and IF/ELSE clauses in filter
condition, and ability to plug-in any type of filter. Adopt help's extension
features and content replace for all other forms of user assistance (e.g.
welcome, cheat sheets). Also provide a better mechanism to
control how UA content is arranged and ordered (for example, the order of
books in the table of contents).
[UA]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175018">175018</a>)
</p>
</blockquote>
<h4>Proposed Items (Components)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Components)</h4>
<blockquote>
<p><strong>API tools.</strong>
More components means more API and an elevated need for solid APIs,
evolved but compatible APIs and the correct and understood use of APIs.
This cannot be achieved without supporting tooling. Today PDE includes
sophisticated support for classpath management and access rule management
based on information in the manifest of bundles to facilitate the capture
of package and class references. In 3.3. we will expand this to cover
finer-grained API contracts (e.g., clients should not call foo() or
extend Bar). Similarly, developers will be given effective mechanisms
for discovering, visualizing and minimizing dependencies in their code,
bundles produced by third parties and non-bundled code libraries. Tooling in support
of checking and managing the evolution of component and package version numbers
will also be supplied.
[PDE]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154078">154078</a>)
</p>
<p><strong>Bundle/Module Development Tools.</strong>
In 3.1 and 3.2 PDE made gigantic strides in support for
traditional OSGi bundle development. Even still, in 3.3. we will improve
various workflows and classpath management strategies to promote the
development of robust and independent right-grained components. This
covers everything from increased quick-fix and manifest editing support
to deeper integration with JDT (e.g., support for searching JARs that
are not in the workspace without implicitly importing the JARs). In
addition, as JSR 291 evolves in the Java SE 6 time frame, PDE will be
there to provide developer support. 3.3 will include tooling around OSGi
Declarative Services and the new application model as well as improved
support for launching other frameworks, Java applications with bundle
based classpaths and "hot launching" frameworks.
<em>(Note: significant work was done on this item, but not enough to cover
it's full scope. See the bug for more info.)</em>
[PDE]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154079">154079</a>)
</p>
<p><strong>Incremental Plug-in Build.</strong>
With the increase in plug-ins coming from and going to third parties the
development cycle needs to be more incremental. In the Eclipse project
itself we have started to consume pre-built plugins such as ICU4J and SSH2.
This trend is likely to continue as, for example, Apache seeks to deliver
their libraries as bundles and more people look to consume individual
bundles/components from Equinox and similar projects. As such, the build
process should support the incremental building of plug-ins (that is
building plugins individually) based on a set of pre-built plugins kept
in some sort of provisioning repository. Plug-ins coming out of the build
should feed into said repository to be used as a base for future builds.
This ability will in turn enable the more frequent building of whole
systems (since you build only what has changed) and simplify incremental,
milestone and release build cycles.
[PDE Build]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154083">154083</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Improved support for provisioning.</strong>
Eclipse has advanced quite quickly with new use-cases (RCP, Equinox,
server side, etc.) and new technologies (e.g., OSGi and OSGi's MEG) coming
into the picture. To date Update Manager has not been enhanced to support
or exploit these changes. In 3.3 we will investigate provisioning support
for enhanced workflows, the ability to update the so-called "root files"
(e.g., startup.jar, eclipse.exe), improved efficiency (download and disk
footprint), support for right-grained discovery and acquisition of function
as well as integration with differing repository types. This effort also
includes enhancements to the tooling around provisioning.
[Update]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154077">154077</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Bundle Management.</strong>
Managing even modest systems of bundles can be complex and error prone. There are
several places in PDE where developers need to list or select sets of bundles (e.g.,
launch configurations, target setup, etc). In many cases the environment already
includes relevant grouping constructs (e.g., features, working sets, bundle groups).
PDE should surface these to developers in a clear, consistent and pervasive
fashion.
[PDE]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154082">154082</a>)
</p>
</blockquote>
<p>(End of items for Components.)</p>
<h2><a name="Consumability">Consumability</a></h2>
<p>
This work will make it easier for users to get Eclipse, install it on
their systems, and configure it for their use. It will also enhance
the error handling and reporting mechanisms to make it easier to service
Eclipse in the field. Finally, it will improve the scalability and
performance of Eclipse, to provide a better experience for users working
with many plug-ins and large data sets.
</p>
<h4>Committed Items (Consumability)</h4>
<blockquote>
<p><strong>Remote help</strong>
Packaging a comprehensive set of help content with a product can significantly
increase its size. Instead of bundling it with the product, allow help content
to be served from a remote infocenter. This includes all forms of help content:
documents, table of contents, keyword index, and context help. Local content is
also allowed alongside the remote content, and it should behave and appear to
the user as though it were installed locally.
[UA, Releng]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175006">175006</a>)
</p>
<p><strong>Improve the launching experience.</strong>
We will look for ways to improve the current launching experience. This
may include efforts such as using SWT to build the splash screen,
improving the look and utility of the workspace launcher, supporting
"fast switching" between workspaces, and simplifying the experience for
first-time users.
[SWT, Runtime, Workspace, UI, UA]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154088">154088</a>)
</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 can diagnose
unexpected behavior such as slow-downs or exceptional memory use. Error
handling is done in a variety of ways within the platform which are not
extensible to RCP applications. An improved story would allow for the
inclusion of application defined error support (such as a link to a support centre
for the product) and remote monitoring/inspection of system health and would
tie the current error reporting story together into a solution with a more
consistent look and fewer error reporting paths for developers.
[Runtime, UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154090">154090</a>)
</p>
<p><strong>Managing and sharing settings.</strong>
Currently settings are either scoped at the workbench/workspace level or the
project level. However, there are cases where associating settings with
other scopes, such as a working set or perspective, would be beneficial.
Similarly, a product should be able to specify the default settings for a
particular perspective. We will also look for ways to simplify how we share
settings and other interesting state, such as breakpoints, bookmarks,
perspectives, key bindings, etc.
[Runtime, Workspace, UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154097">154097</a>)
</p>
<p><strong>Platform level proxy settings.</strong>
There are at least three proxy settings pages in Callisto. We will work with
the Eclipse community to make sure that the core capabilities from these
pages are made available at the Platform level, as a single settings
page that can be consumed by all.
[Runtime, Team, Update, UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154100">154100</a>)
</p>
<p><strong>GTK Printing.</strong>
We will provide printing support on GTK.
[SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154101">154101</a>)
</p>
<p><strong>Search based navigation.</strong>
Because traditional navigation-by-browsing does not scale to large data
sets, we should generalize and extend the existing search-based
rapid navigation mechanisms (e.g. "Quick Find Class").
[UI, UA]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154104">154104</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> committed)
<strong>Performance focus.</strong>
We must continue to improve overall performance and memory consumption,
with a particular focus on working with large numbers of plug-ins and
large amounts of data.
[All components]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154106">154106</a>)
</p>
</blockquote>
<h4>Proposed Items (Consumability)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Consumability)</h4>
<blockquote>
<p><strong>Customization.</strong>
Eclipse lacks customization capabilities aimed at end users and product
packagers. More generally, component development and use is fraught with
producer/consumer problems. Component producers implement solutions that
address a number of use-cases and scenarios but inevitably consumers come
up with additional, sometimes quite divergent requirements. We will
investigate mechanisms and facilities that allow component consumers to
"override" or replace metadata specifications in the components they are
consuming. Such mechanisms would, for example, allow consumers to configure
menus, tool bars, and perspectives of their Eclipse installation as well
as refine plug-in dependency declarations.
[Runtime, UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154099">154099</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Help keyword index</strong>
In 3.2, keyword index support was added to the Help system. However, as yet the
Eclipse SDK does not have keyword index content. This item consists of
contributing a comprehensive and complete keyword index for Eclipse as
well as the necessary tooling to create it (e.g. ant task to extract meta
keywords from html, etc). This also includes UI enhancements for the overall
presentation of the keyword index and any necessary usability enhancements.
[UA, Doc]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175008">175008</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Ship Finer-grained Components.</strong>
The Eclipse project produces three major outputs, the Platform, JDT and PDE.
These are exposed as zips on download sites and features on update sites.
Those wanting to get just part of one of these components (e.g., Help,
Update, JDT Core) must first discover which zip or feature contains the
desired function, acquire that container and finally identify and extract
the desired plug-ins. To make this easier we will revise the grouping structure
to capture more independent and re-usable components.
[All components]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154102">154102</a>)
</p>
</blockquote>
<p>(End of items for Consumability.)</p>
<h2><a name="Java">Java</a></h2>
<p>
The Eclipse Java Development Tools are the premier Java development
environment in the industry today. We must address the new capabilities
of Java SE 6 and continue to refine and extend the features JDT provides to
maintain its leadership position.
</p>
<h4>Committed Items (Java)</h4>
<blockquote>
<p><strong>Enhance launching support.</strong>
We should simplify the launch experience for novice users with single
click, context sensitive launching, and with launch configurations
managed via resource properties. For advanced scenarios, we should
allow plug-ins to contribute additional pages to launch configurations so
that plug-in specific information (such as profiling and code coverage settings)
can be associated with each configuration. Additionally we should support
mixed mode launching, and allow more than one plug-in to contribute launchers
for the same configuration type and mode (allowing the user to select a
preferred launcher).
[Debug]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154107">154107</a>)
</p>
<p><strong>Extend Clean Up.</strong>
Add formatting, organize import and sort members to 'Clean up',
offer clean up profiles, and invoke clean up on user defined events.
[JDT UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154109">154109</a>)
</p>
<p><strong>Compiler API (JSR 199).</strong>
In order to conform to the forthcoming tool API for compilers (JSR 199),
the Eclipse compiler should provide a front-end implementing the tool API
included in Java SE 6.
[JDT Core]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154111">154111</a>)
</p>
<p><strong>Support for Java SE 6 debug features.</strong>
Implement new Java SE 6 features in the Eclipse Java Debug Interface (JDI)
client including support for heap walking (retrieve instance counts, all
intances of specific types, and all references to an object), forcing an
early return from a method with a specific return value, and improved class
prepare event filtering.
[JDT Debug]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154115">154115</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> committed, wording has changed)
<strong>Enhance Annotation Processing Tooling.</strong>
APT should support the new standard Annotation Processing API (JSR 269)
introduced in Java SE 6, as opposed to the provisional API from Sun
introduced in Java SE 5 that is currently implemented. Also, the APT
integration in IDE should be improved in various areas, including editor
reconciling and code assist. The editor reconciling experience should work
correctly even if the Java builder is not active. Currently, if a processor
generates types, those types are ignored during reconcile. Instead, they
should be modeled using working copies, and provide the same level of
functionality as JDT when autobuild is turned off. Also, on the code-assist
front, we should provide a simple API for processors to supply domain
specific knowledge to completions inside annotation values.
[JDT APT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154110">154110</a>)
</p>
</blockquote>
<h4>Proposed Items (Java)</h4>
<blockquote>
<p><strong>More refactorings.</strong>
We will finish the 'Fix Deprecation' refactoring that didn't make it
into 3.2, and add the new refactoring 'Replace Invocation'. More
refactoring API will be offered in the plug-in org.eclipse.jdt.core.manipulation
so the refactoring infrastructure can be used with a UI.
[JDT UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154108">154108</a>)
</p>
</blockquote>
<h4>Deferred Items (Java)</h4>
<blockquote>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Add more class file targets for compiler.</strong>
The compiler should support more configurable class file targets, including
CLDC 1.0, CLDC 1.1 and possibly JSR 14 (generics experimentation for 1.4
VMs).
[JDT Core]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154113">154113</a>)
</p>
</blockquote>
<p>(End of items for Java.)</p>
<h2><a name="Vista">Vista</a></h2>
<p>
Microsoft Vista is a significant new desktop platform that we expect
will become available during this development cycle. We should fully
support running the current, win32-based version of Eclipse on
Vista. We should also port SWT to WinFX and the Windows Presentation
Framework.
</p>
<h4>Committed Items (Vista)</h4>
<blockquote>
<p><strong>Fully support the win32 version of SWT on Vista.</strong>
We should ensure that applications built on the win32 version of
SWT work as well as any other win32 API based application on
Vista. This will increase our testing and support effort and potentially
require new development to work around platform specific differences. [SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154116">154116</a>)
</p>
<p><strong>Port SWT to WinFX and WPF.</strong>
We should port SWT to WinFX and the Windows Presentation Framework. Since
64-bit systems are becoming increasingly prevalent on the desktop, we should
ensure that this port is both 64-bit and 32-bit capable.
<em>(Note: In the 3.3 timeframe, we are committed to producing a WPF port
that will be suitable for early access style investigation on the platform.
Significant follow on performance and feature completeness work (such as 64-bit
support) will occur in our next release.)</em>
[SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154117">154117</a>)
</p>
</blockquote>
<h4>Proposed Items (Vista)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Vista)</h4>
<blockquote>
<p><strong>Generalize the win32 version of SWT to win64.</strong>
We should merge the work being done by the Eclipse community to implement
a win64 implementation of SWT into the main win32 code base. This will
require extensive review of the new code and a significant effort to merge
and test the pervasive changes.
[SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154118">154118</a>)
</p>
</blockquote>
<p>(End of items for Vista.)</p>
<h2><a name="UIEvolution">UI Evolution</a></h2>
<p>
The goal of this work is to provide a better basis for building modern,
rich user-interfaces, by addressing areas where more flexibility and
more consistency are needed. We will use these capabilities to refine
the user-interface of the Eclipse IDE. In addition, we will implement
of the most requested missing IDE productivity features.
</p>
<h4>Committed Items (UI Evolution)</h4>
<blockquote>
<p><strong>Investigate background saving of editors.</strong>
Modern applications allow editing sessions to be saved in the background,
allowing the user to continue editing or close the editor without waiting.
We should investigate whether this style of interaction can be built
on top of the Eclipse editor framework. [Platform Text, JDT Text, Platform UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154122">154122</a>)
</p>
<p><strong>Improve workbench usability.</strong>
We should review how users interact with the workbench, such as
how editors, views, and other screen real-estate are managed
(e.g. fix the broken minimize), and find ways to make this a better
experience for them. This includes improving the new trim
support by allowing the end user to hide/show, close and otherwise
configure trim items, improving navigation from hovers (e.g. quick diff),
making fast views more flexible (fast views on all sides, fast view
orientation affinity, fast view bars show text option).
[Platform UI, Platform Text, JDT UI, JDT Text]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154120">154120</a>)
</p>
<p><strong>Mozilla Everywhere.</strong>
For situations where the existing, platform-browser-based Browser
control is not sufficient, we should support embedding of Mozilla on all
platforms. This would allow developers to implement code that worked
against a common back end, so that they could access a common DOM, or
surface the browser's HTML editing support.
[SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154124">154124</a>)
</p>
<p><strong>UI Forms face-lift</strong>
UI Forms will be refreshed visually and functionally. Color management will be
revised to increase consistency of color across all the platforms Eclipse runs
on. Enhancements will be made to both the header area and field decoration support.
Eclipse SDK clients of UI Forms will take advantage of the new capabilities.
[UA, PDE]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175158">175158</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> committed, wording has changed)
<strong>JFace Enhancements.</strong>
Ensure that the reusable components in JFace fully support the SWT
widget set, such as support for the new custom draw capabilities
of the Table and Tree widgets. Also, implement some of the components
that we do not use in the SDK currently that the community is
requesting.
[Platform UI, SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154123">154123</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> committed)
<strong>Implement missing text editor productivity features.</strong>
We should provide some of the long awaited productivity features that
the community has voted for. Examples include double-click-drag to
select multiple words, triple-click, extensible hyperlink support
and spell checking. [Platform Text, Platform UI, SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154119">154119</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> committed, wording has changed)
<strong>Ubiquitous cheat sheets</strong>
Cheat sheets will be commoditized by lowering the price of authoring and
publishing. We will make it easy to whip up a cheat sheet quickly, hook
appropriate commands for 'Do it for me' links, exchange cheat sheets as
attachments or as URLs to remote cheat sheets.
[UA, PDE, Doc]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175024">175024</a>)
</p>
</blockquote>
<h4>Proposed Items (UI Evolution)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (UI Evolution)</h4>
<blockquote>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Improve multi-instance view management.</strong>
Views such as Search and Synchronize use a drop-down menu to manage
multiple pages. Another possibility would be to use multiple view instances.
However, the presentation and management of these two approaches are different.
Multiple view instances should support different view presentations. That is,
the user (or product) should be able to decide whether multiple views use tabs
or a drop-down menu. There are also shortcomings in multi-view management
(e.g., views are managed at the perspective level but some tooling may require
the ability to close a particular view in all perspectives).
[UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154121">154121</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> deferred)
<strong>Help webapp refresh</strong>
The Help web application's appearance does not currently match the workbench
appearance well. However it is common for users to move back and forth between
these two windows, resulting in an inconsistent experience for the user.
We will refresh several aspects of the Help user experience, including
presentation, accessibility issues, optional footer for legal information,
automatic bread crumbs. <em>(Note: significant work was done on this item,
but not enough to cover it's full scope. See the bug for more info.)</em>
[UA]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175023">175023</a>)
</p>
</blockquote>
<p>(End of items for UI Evolution.)</p>
<h2><a name="API">API</a></h2>
<p>
This work area deals specifically with issues concerning the application
programming interfaces provided by the Eclipse Project. We will identify
API whose function has been superceded, and ensure that the SDK does
not depend on this API. We will encourage adoption within the SDK of
some of the more recent additions to Eclipse, such as
the command framework, Equinox preferences, tabbed
properties and the common navigator. We will work with the community to
ensure that needed functionality is made available as API, when it reaches
appropriate levels of maturity.
</p>
<h4>Committed Items (API)</h4>
<blockquote>
<p><strong>Generalize editor annotation and ruler support.</strong>
We should allow plug-ins to contribute additional vertical rulers
to show additional information (e.g. code coverage). We should
support live annotate "color by age" in addition to "color by
contributor".
[Platform Text]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154125">154125</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> follow on work in next release)
<strong>Adopt the new UI features.</strong>
We should adopt the following items across the entire SDK UI: the new
command framework, preference initializers, field assist, SWT column
sort indicators, working sets, tabbed properties view and the common navigator.
<em>(<img src="new.gif" alt="(new)" border="0" height="12" width="12">
Note: This is an ongoing effort that will continue in the next release of Eclipse.)</em>
[UI, JDT UI, PDE, Team, Text]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154127">154127</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> wording has changed)
<strong>Provide access to more native controls.</strong>
We should provide access to more of the native controls that are available
on each platform, such as date and time pickers.
In addition, we should enable more features of existing native controls.
[SWT, UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154128">154128</a>)
</p>
<p><strong>Custom widget API support.</strong>
Investigate ways to simplify the process of writing custom widgets,
including making available, as API, some of the currently internal
capabilities of the custom widgets implemented in the SDK, such as
drag under feedback for drag & drop.
[SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154129">154129</a>)
</p>
<p><strong>Finish re-work of commands and key bindings.</strong>
In 3.2, we built some important infrastructure that will allows us to
rationalize our commands and key bindings story. We need to complete this
effort, making sure the new story supports all of the existing
functionality (e.g action sets), and migrate over to the new support.
We also need to make it easier to add and edit key bindings.
[UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154130">154130</a>)
</p>
<p><strong>JFace data binding.</strong>
In 3.2, we developed a data binding framework for JFace but did not
make it generally available. We should continue to work towards providing a
public API for this framework and investigate how it will be delivered and
used within the SDK.
[UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154132">154132</a>)
</p>
<p><strong>Improve compare.</strong>
The Compare plugin has not undergone much work in the last few releases
and is showing it. From an architectural standpoint, there are several
Compare internals that need to be made API in order to properly support
clients and there are also several polish items that have been identified
by Eclipse development teams. In addition, new ISaveable support was added
in 3.2 and we should investigate integrating this into Compare. From a
usability standpoint, the compare editor uses a custom viewer for content
which appears similar to the related editor but has a reduced capability
which is often confusing for users. Smaller usability issues involve
breaking out the outline from the editor into the Outline view. There is
supported by compare but is not used by Team or other Platform clients.
[Team]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154133">154133</a>)
</p>
<p><strong>Graphics Improvements.</strong>
The SWT graphics layer should provide support for fractional line widths,
dashes and fonts, the ability to flatten paths, image loading/saving
improvements, and other similar enhancements.
[SWT]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154134">154134</a>)
</p>
<p><strong>APIs for custom debugger integration.</strong>
Publish public APIs based on the provisional APIs introduced in 3.2 to
support custom debugger integration. Features include a debug context
service supporting retargettable actions and debug command handlers
(for operations such as step and terminate), custom detail panes in the
variables view, flexible view wiring and pluggable source lookup.
[Platform Debug]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154135">154135</a>)
</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> committed)
<strong>Adopt the Eclipse File System.</strong>
We should ensure that use of the Eclipse File System is pervasive
in the platform, and remove any barriers that prevent it from being
more widely adopted by the community. For example, we should provide
IFileStoreEditorInput and a matching default implementation.
[Workspace, UI, Platform Text]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154126">154126</a>)
</p>
</blockquote>
<h4>Proposed Items (API)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (API)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for API.)</p>
<!-- End of Sections by Work Area -->
<h2><a name="Appendix1">Appendix 1: Execution Environment by Plug-in</a></h2>
<p>In the table below, the "3.3 EE" ("3.3 Execution Environment") column
indicates the minimum Java class library requirements of each plug-in
for the 3.3 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 specification 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
specification 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.3.</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.4.</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>
<div align="center"><strong>1.4/1.5</strong></div>
</td>
<td>Indicates that the plug-in can run on JSE
1.4 or greater, but provides enhanced functionality when run on J2SE 5.0.</td>
</tr>
<tr>
<td>
<div align="center"><strong>1.5</strong></div>
</td>
<td>J2SE 5.0 - indicates that the plug-in can only be run on JSE
5.0 or greater.</td>
</tr>
<tr>
<td>
<div align="center"><strong>1.6</strong></div>
</td>
<td>J2SE 6.0 - indicates that the plug-in can only be run on JSE
6.0 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.3 EE</strong></div>
</td>
</tr>
<tr>
<td>javax.servlet</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>javax.servlet.jsp</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.apache.ant</td>
<td>
<div align="center">1.2</div>
</td>
</tr>
<tr>
<td>org.apache.commons.el</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.apache.commons.logging</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.apache.jasper</td>
<td>
<div align="center">F1.0</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">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.commands</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.contenttype</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.jobs</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.net</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.runtime.compatibility.auth</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.core.runtime.compatibility.registry</td>
<td>
<div align="center">F1.0</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.equinox.app</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.common</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.http.jetty</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.http.servlet</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.http.registry</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.jsp.jasper</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.jsp.jasper.registry</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.launcher</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.preferences</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
<tr>
<td>org.eclipse.equinox.registry</td>
<td>
<div align="center">F1.0</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.apt.core</td>
<td>
<div align="center">1.5</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.apt.ui</td>
<td>
<div align="center">1.5</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.compiler.apt</td>
<td>
<div align="center">1.6</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.compiler.tool</td>
<td>
<div align="center">1.6</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.core</td>
<td>
<div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.core.manipulation</td>
<td>
<div align="center">1.4</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.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.junit.runtime</td>
<td>
<div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.junit4.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.4</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.jsch.core</td>
<td>
<div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.jsch.ui</td>
<td>
<div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ltk.core.refactoring</td>
<td>
<div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ltk.ui.refactoring</td>
<td>
<div align="center">1.4</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.pde.ui.templates</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.navigator</td>
<td>
<div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.navigator.resources</td>
<td>
<div align="center">1.4</div>
</td>
</tr>
<tr>
<td>org.eclipse.ui.net</td>
<td>
<div align="center">1.4</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>org.mortbay.jetty</td>
<td>
<div align="center">F1.0</div>
</td>
</tr>
</tbody>
</table>
</body>
</html>