Google Git
Sign in
eclipse / www.eclipse.org / eclipse / 283e5aa56519b7305d9800532d37435bbb478daf / . / development / eclipse_project_plan_3_3_tnexxx.html
blob: d3d9d10429fd956e3fce0352144b39c0f76fae90 [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>Not The Eclipse Platform Project Draft 3.3 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>
<h1>Not The Eclipse Project DRAFT 3.3 Plan</h1><h2 align="center">
<font color="#ff0000">
<h2 align="center">WARNING WARNING WARNING</h2>
<h2 align="center">
This document is just a work area for the Eclipse Project PMC to record an
essentially random list of possible ideas for R3.3. Do not assume
believe you understand <big>ANYTHING</big> about what we will be doing
based on this content!
</h2>
<h2 align="center">WARNING WARNING WARNING</h2>
</font></h2><font></font>
Last revised 17:03 EST Feb 14, 2006
(<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_20051109.html">draft of Nov. 9, 2005</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="#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>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 the 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>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> Friday Feb. 17, 2006 - Milestone 5 (3.2 M5) - stable build - API complete - API freeze</li>
<li> 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 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.
</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.).
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
With the exception of a small set of planned features that
actually require Java SE 5 APIs (most notably, the support for
Annotation Processing and JUnit 4), the 3.2 release of the Eclipse
Project is developed against version 1.4 of the Java 2 Platform.
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.
<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 <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" style="width: 821px;" border="1">
<tbody>
<tr bgcolor="#cccccc">
<th colspan="5">
<div align="center"><strong><font size="+1">Eclipse Reference Platforms</font></strong></div>
</th>
</tr>
<tr>
<td width="205"><b>Operating system</b></td>
<td width="59"><b>OS version</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</td>
<td width="59">XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">
Sun Java 2 Standard Edition 5.0 <s><font color="#ff0000">Update 4</font></s> Update 6<br>for Microsoft Windows
</td>
</tr>
<tr>
<td width="205">Microsoft Windows</td>
<td width="59">XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">
IBM 32-bit SDK for Windows,<br>Java 2 Technology Edition 5.0
</td>
</tr>
<tr>
<td width="205">Microsoft Windows</td>
<td width="59">XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
Sun Java 2 Standard Edition 1.4.2_10<br>for Microsoft Windows
</td>
</tr>
<tr>
<td width="205">Microsoft Windows</td>
<td width="59">XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
IBM 32-bit SDK for Windows,<br>Java 2 Technology Edition 1.4.2 service release 3
</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux</td>
<td width="59">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,<br>Java 2 Technology Edition 5.0
</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux</td>
<td width="59">WS 4</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
Sun Java 2 Standard Edition 1.4.2_10<br>for Linux x86
</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux</td>
<td width="59">WS 4</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
IBM 32-bit SDK for Linux on Intel architecture,<br>Java 2 Technology Edition 1.4.2 service release 3
</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux</td>
<td width="59">WS 4</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">
Sun Java 2 Standard Edition 5.0 <s><font color="#ff0000">Update 4</font></s> Update 6<br> for Linux x86</td>
</tr>
<tr>
<td width="205">SUSE Linux Enterprise Server</td>
<td width="59">9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
Sun Java 2 Standard Edition 1.4.2_10<br>for Linux x86</td>
</tr>
<tr>
<td width="205">SUSE Linux Enterprise Server</td>
<td width="59">9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
IBM 32-bit SDK for Linux on Intel architecture,<br>Java 2 Technology Edition 1.4.2 service release 3
</td>
</tr>
<tr>
<td width="205">Sun Solaris</td>
<td width="59">10</td>
<td width="76">SPARC</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">
Sun Java 2 Standard Edition 1.4.2_10<br>for Solaris SPARC</td>
</tr>
<tr>
<td width="205">HP HP-UX</td>
<td width="59">11i</td>
<td width="76">hp9000<br>PA-RISC</td>
<td width="59">Motif</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
HP-UX JDK for the Java 2 Platform Standard Edition for 1.4.2_09
</td>
</tr>
<tr>
<td width="205">IBM AIX 5L</td>
<td width="59">5.2</td>
<td width="76">Power</td>
<td width="59">Motif</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
IBM 32-bit SDK for AIX,<br>Java 2 Technology Edition 1.4.2 service release 3
</td>
</tr>
<tr>
<td width="205">Apple Mac OS X</td>
<td width="59">10.4</td>
<td width="76">Power</td>
<td width="59">Carbon</td>
<td width="453">
<img src="new.gif" alt="(new)" border="0" height="12" width="12">
Java 2 Platform Standard Edition (J2SE) 1.4.2<br>service release 2 for Tiger
</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux</td>
<td width="59">WS 4</td>
<td width="76">Power</td>
<td width="59">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, <br>Java 2 Technology Edition 1.4.2 service release 3
</td>
</tr>
<tr>
<td width="205">SUSE Linux Enterprise Server</td>
<td width="59">9</td>
<td width="76">Power</td>
<td width="59">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, <br>Java 2 Technology Edition 1.4.2 service release 3
</td>
</tr>
<tr>
<td width="205">SUSE Linux Enterprise Server</td>
<td width="59">9</td>
<td width="76">Power</td>
<td width="59">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, <br>Java 2 Technology Edition 1.4.2 service release 3
</td>
</tr>
</tbody>
</table>
<p>Because Java 1.4.2 platforms are used for most Eclipse development,
in general, 1.4.2 platforms are listed here. Of course, the teams doing Java 5 based
development are using Java 5 platforms, and the specific ones that they test on
are also included. <i>We expect that Eclipse will work fine on other Java 5 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: 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
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>
<h2>Philippe's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Performance watch</strong>
Continue to monitor overall performance and memory consumption. This includes the addition of new performance tests for new features.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>More text editor productivity features</strong>
Provide some long awaited productivity features like double-click-drag to select multiple words, tripple-click, extensible hyperlink support and spell checking. Some of the items depend on support from Platform UI and Platform SWT [Platform Text, Platform UI, Platform SWT] []
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Better progress reporting everywhere.</strong>
We have numerous cases where our progress is poor, and does not provide more information than a busy cursor.
We should invest for providing better heuristics. Polish item, but which likely needs decent attention upfront.
(see for example <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><em>Better gauging of progress when building workspace</em></a>)
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Dani's Item</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Polish / Wish List Pass</strong>
I suggest an additional polish / wish list pass early because in our normal polish pass, we often ignore items saying it's too late and/or too risky to do them so late in the game.
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Martin's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improve Search/Replace usability</strong>
In 3.2, we experimented with modeless UI, that didn't make it in the product as it was to judged to different to the existing views in the platform. However, especially the current replace UI is in very bad shape. We want to consult with the UI designers if it makes sense to embed input fields in the search result view. Other topic are to start showing line matches (new opportunities with custom tree item rendering) and to investigate how we can help the user with entering regular expressions.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>RCP split for search plug-in</strong>
We have several requests (bug 77424) for splitting the search plug-in in a resource less part (dialogs, search result view framework) and a resource dependend part (file search functionality). First investigations have shown that this should be possible without breaking API. The split could even be used to separate the APIs of the 'old search' that was deprecated in 3.0.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Nick's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improve Usability</strong>
Improve the usability of the fundamentals of the workbench: editor and view management, perspective management, other screen real-estate management (i.e. fix the broken minimize). Also, for the new trim support, we need the ability to allow the end user to hide/show items. There are also important requirements from existing clients: sidebar views (should look at integrating with sticky views), enable to programmatically control layout (e.g. to show 4 image editors arranged in a grid). For navigating the workspace (and/or Java model), we should explore other ways, e.g. web-style navigation with breadcrumbs bar at top, with either drop-downs or editors for picking items from containers.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Parameterize default presentation</strong>
For RCP applications we need to allow parameterization of the default presentation. We've had three releases for the community to come up with decent presentation implementations, and it hasn't happened. They're just hard to do, both technically, and graphic-design-wise. This could be done using preferences (possibly hidden) for whether min/max buttons are shown, more control over tab compression, icon appearance, MRU ordering of tabs, support for large icons (kiosk mode) etc.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Boris/Tod/MVM Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<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. 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 some sort of application defined error support (such as a link to a support centre for the product) and would tie the current error reporting story together into a solution with a more consistent look and fewer paths for developers to report errors to. (106193,124964)
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Presentation Refresh</strong>
Currently the Workbench Presentation is tied into the presentations API through workbench internals. This presentation should be split out into a 3.0 presentation. When this is done a refresh of the look of the IDE would be done in order to keep a modern, fresher look to the SDK.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Scoped Listeners</strong>
Currently the listener mechanism sends updates to all registered listeners regardless of how the update was created. In the workbench level mechanisms like the decorators mechanism this results in the update of every object that registers a listener, resulting in uneccessary updates. Providing some way of scoping these listeners that allows for reduced updates will allow for only those listeners interested to get updated.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Make Resource Dependant Components available for RCP</strong>
Currently anyone wanting to use the Progress, Problems, Tasks or Bookmarks view is required to also use the IDE application as the IDE is not an RCP component. Resource based components that could be used for RCP applications should be split out into another plug-in. A next step in this direction is to allow reuse of these views whithout having to depend on resources.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Re-think the Import/Export mechanism. (this is an update from McQs original)</strong>
The current import/export dialogs include numerous capabilities that users do not expect to see. We need to distinguish between mechanisms for sharing state (such as Preferences) versus actual format converting operations, which are what import/export is traditionally used for. We should also investigate data synchronization as an alternative. The Platform currently provides dialogs for Import and Export of Files, Archives and Existing Projects. These can be combined into one dialog each so as to reduce confusion and to simplify our code base.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>JFace Components</strong>
Currently the reusable components in JFace focus on supporting the SWT widget set and adding functionality for the SDK. There are numerous other components that we do not use in the SDK currently that the community is requesting. Some examples would be: date and time field editors, spinners, secure editors (such as password entry fields) fields that enforce a format (such as field for currency and percentages), spreadsheet
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Support GB18030-2 (Deferred from 3.2)</strong>
The GB18030-2 Chinese character set is becoming increasingly important in the Java community. Eclipse should support GB18030-2 on platforms where it is supported natively. Because of the fundamental and far reaching impact of implementing this support, it is expected that it will require an SDK (and indeed entire Eclipse Foundation) wide strategy.(127864)
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improved BIDI Support</strong>
There are still some holes in the BIDI story in the workbench to do with rendering of mixed RTL and LTR string. (130587)
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Use SWT to build the splash screen</strong>
The current splash screen is implemented by a wad of C code. This is less than ideal for many reasons, including that it is platform specific, not very flexible (e.g. no PNG images, does not support non-rectangular areas) and difficult to update.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Finish re-work of commands and key bindings</strong>
In 3.2, we built some important infrastructure that will allow 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 migrating over to the new support. We also need to make it easier to add and edit key bindings. [Theme: Ease of Use]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Customizable UI</strong>
Eclipse is not customizable enough from an end user's perspective. In 3.2, we made trim items draggable by the end user. We need to do the same for menus and tool bars, and allow users to show and hide actions over what is currently possible using action sets. We also need to simply how the user makes these modification by replcing complicated UI elements like the Customize Perspective dialog
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Scripting</strong>
Based on the work in the Dash project on simple scripting, and the new command infrastructure, we are now in a much better position than ever to tackle the issue of making Eclipse scriptable. This includes providing useful DOMs for scripts to call into, but also providing events within Eclipse for scripts to hook into (e.g., onPartActivate, onOpenProject etc.), and a way to record scripts by collecting the executed commands and their parameters.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Workbench Refactoring</strong>
There are some areas where new API completely replaces old API, including but not limited to core expressions replacing common expressions and the new commands/keybindings story. We should refactor obsolete API and functionality into a separate plug-in, thereby making it easier to understand which API is recommended, reducing the size of the Workbench plug-in, and making the Workbench more maintainable in the long run.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improved Workspace Launcher</strong>
The workspace chooser dialog where you select your workspace is confusing to first-time users, and not very useful for advanced users. The workspace launcher should be more helpful to first-time users, for exampe by moving parts of the Welcome view into it, and provide real value for advanced users, for example by enabling browsing of existing workspaces (and displaying information like unreleased outgoing changes).
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>JFace Data Binding</strong>
In 3.2, we developed a data binding framework for JFace but decided to not make it public API. We should finalize the API and start using it where appropriate.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Nesting parts (Deferred for 3.1 and 3.2)</strong>
Various problems are encountered when trying to nest workbench parts (editors or views). For example, the current compare infrastructure cannot reuse the existing Java editor to provide the regular editing experience including key bindings, content assist etc. The UI needs to support nesting of workbench parts, and reduce the coupling of parts to particular locations in the workbench, allowing for more flexible UI configurations.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Michael V's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Scalability (A UI item that relates to Team)</strong>
In general, we should look at ways of improving scalablility. One specific instance of this involves view defined by the Platform. We should investigate way to make these views tailorable to the context in which they appear. For instance, if the Problems view appears in a higher-level models perspective, errors from lower level models could be filtered out by default. The Project Explorer is another example view that, when shown in a higher-level models perspective, shoudl show the content from that model associated with the perspective and filter out unrelated models. These are just a couple of concrete examples. we should use Callisto and other clients as a testbed for experimentiong on these and other scalability scenarios to improve the user experience.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Team/CVS and Eclipse.org</strong>
We need to ensure that the Team platform and the CVS plugin meet the requirements of other Eclipse.org projects. Specifically, we need to ensure that the workspace structure required by the Eclipse.org projects is supported by the Team architecture and the CVS client. We also need to ensure that the CVS plugin continues to meet the needs of the Eclipse development teams.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Compare (A Compare item related to Team)</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.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improve Multi-instance view management</strong>
The Synchronize view uses a dropdown to manage multiple pages. Another possibility would be to use multiple view instances. However, the presentation and management of these two approaches are different. It would be nice if the decision to use multiple view instances still supported different view organizations. That is, the user (or product) could decide whether multiple views used a tab or dropdown. There are also shortcomings in multi-view management (i.e. views are managed at the perspective level but some tooling may require the ability to close a particular view in all perspectives).
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improve job interaction</strong>
Improving Job interactions includes ensuring that the progress view is showing the user meaningful and up-to-date information. Another issue is the handling of prompting from a background job. Currently, dialogs are shown directly from the job which can interrupt the users current task. A less intrusive but still effective means of notifying the user of the prompt would be good. Error reporting from background jobs should also be investigated. Currently, an error dialog is shown and the errors are written to the error log. As with other prompting, a less intrusive means is desirable and it would also be good if not all errors were logged (or perhaps a separate logging location could be used).
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Adoption of new Platform APIs by Team/CVS</strong>
There have been several new APIs added in 3.2 that the Team/CVS component has not stepped up to. These include the Commands framework, field assist, SWT column sort indicators,etc. In 3.3, we should step up to the latest APIs and also adopt other API changes as they occur to ensure that any new APIs introduced in 3.3 get as much tesing as possible.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Cache Management</strong>
The CVS client uses several caching mechanisms. These include a sync info cache, file contents cache, project tag cache. The management of these caches is rather ad hoc at the moment. For instance, the file content cache will clear entries after a certain time and frees the entire cache across a restart. However, some cached file entries could be kept across restart to improve performance (i.e. the contents associated with the base revision of a modified workspace file). Some caches (e.g. sync info cache) are lazily loaded into memory but are never unloaded. The project tag cache is also lazily loaded and never unloaded with the added dimension that the on-disk cache could also be cleared if disk usage was too high. We should look at ways of providing cache management strategies that will help CVS with an eye towards whether the resulting mechanisms are more generally applicable.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Remote Explorer</strong>
With the introduction of the Common Navigator, it is now easy to define a generic remote explorer in the Team perspective (https://bugs.eclipse.org/bugs/show_bug.cgi?id=138583). The Remote Explorer would just define a place holder in the Team perspective to which repository providers or other tooling providers could contribute remote content as Common Navigator content extensions. The explorer would also need to provide support for the creation of new remote locations to be browsed using the Common Navigator wizard support.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Platform level proxy settings (Really a Runtime item)</strong>
There are at least 3 proxy settings pages in Callisto. There should be a Platform level setting and a single preference page to configure the proxy settings (https://bugs.eclipse.org/bugs/show_bug.cgi?id=119278)
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Steve's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Vista Port</strong>
SWT should be implemented on top of WinFX and WPF (Windows Presentation Framework).
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Theme and Branding</strong>
In order to allow the community to customize the look of Eclipse based applications we need the ability to draw custom controls that look like operating system controls, the ability to custom draw more native and custom controls (ToolBar, CTabFolder ...), and API's to support branding.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Graphics Improvements</strong>
The SWT graphics layer should provide support for fractional line widths, daches and fonts, the ability to flaten paths, and image loading/saving improvements, and similar enhancements.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Mozilla Everywhere</strong>
We should support embedding Mozilla on all platforms.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>GTK Printing</strong>
We should provide printing support on GTK.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Win64</strong>
We should support 64-bit windows.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>New Widgets</strong>
SWT should provide access to more native controls (Header, Date and Time picker ...).
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Mac Improvements</strong>
The Mac implementation of SWT should be brought up to the level of the other platforms by providing implementations for the following missing features: in-line IME, BIDI, accessibility, system tray, dock improvements.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Darin's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>APIs for custom debugger integration (was originally named "Enhance the debug platform")</strong>
Publish public APIs based on the provisional APIs introduced in 3.2 to support custom debugger integration. Features include flexible hierarchy in debug views; asynchronous, cancellable interactions when retrieving content and labels; model driven view updates; a debug context service for retartgettable actions, flexible view wiring and pluggable source lookup. [Theme: Design for Extensibility, Enterprise Ready] [Platform Debug]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Simplify launching support (was originally named "Enhance launching support")</strong>
Simplify the launch experience for novice users with single click context sensitive launching. Allow launch configurations to be managed via resource properties. Support user configurable toolbar buttons to invoke favorite launch configurations. [Theme: Simple to Use][Platform Debug, JDT Debug]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Launch support for RCP (was originally named "Enhance launching support")</strong>
Seperate launch support into a new plug-in such that launching can be performed without requiring debug plug-ins. Support launching in a combination of modes rather than the current mutually exclusive modes (for example, the ability to profile and debug an application at the same time). Investigate combining run, debug, and profile actions into a single execute action with launch modes being specified by a launch configuration. Support a launch configuration namespace allowing for more than one configuration with the same name. Support launch configuration templates allowing common launch settings to be shared among a group configurations. Allow clients to override standard console creation for system processes. [Theme: Design for Extensibility, Enterprise Ready] [Platform Debug]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Extensible debug views with pin and clone support</strong>
Allow debug clients to plug custom controls into the variables view details pane (also registers view and expressions view). Support the ability to pin a debug view to a specific debug session and clone views to allow side by side comparison of different debug sessions. [Theme: Design for Extensibility, Enterprise Ready] [Platform Debug]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
</blockquote>
<h4>Deferred Items (Eclipse Platform project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</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>
<h2>Philippe's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Polish the look and feel of JDT UI</strong>
The new SWT capabilities added late in 3.2 open new opportunities for the JDT views and dialogs. In 3.3 we would like to take advantage of custom rendering of tree and table items to better structure the presented information using different colors and styles. We also want to improve affordance for quick fix, quick hierarchy and outline to move towards a new, fast view oriented, Java perspective. We want to replace some of the refactoring dialogs with lighter versions, using the good experiences with quick hierarchy and quick outline.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Continuously improve refactorings.</strong>
We want to finish the fix deprecation refactorings which didn't make it into 3.2, and add the new refactoring 'Replace Invocation'. More refactoring API can now be offered in the new plug-in jdt.core.manipulation so the refactoring infrastructure can be used head-less.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Extending Clean Up</strong>
We want to add formatting, organize import and sort members to 'Clean up', offer clean up profiles, and invoke clean up on user defined events.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Code audit integration</strong>
The goal is to standardize how and when code audits (our own and contributed) are invoked and presented in the UI as well as to provide core infrastructure. Some code audits can be computed 'as you type', others require deep analysis that can't be done while building but has to be kicked on by the user or other events. We have to discuss where and how code audit result are presented (e.g. in the problems view or in a new code audit view) and if we want to provide infrastructure for the code audit preference pages. Core infrastructure would allow code audits to share resources as the AST.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>More flexible project layout</strong>
When adopting Eclipse, some pre-existing project layouts are hard to model in Eclipse. It feels this process could be eased by allowing more configurability of the Java project, such as allowing custom buildpath or settings on a per source folder basis; multiple source attachments per library; inclusion of external resources in workspace (as opposed to linking resources which is not seen by external tools); relax classpath container limitations, which currently do not allow nested containers, source folders etc...
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>APT command-line tool</strong>
Annotation processing tooling got integrated on top of the Java IDE within release 3.2. Looking further, it should also be made available as a command-line tool, as a complement to the batch compiler and/or Ant javac adapter.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Compiler API (JSR199)</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.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>More classfile targets for compiler</strong>
The compiler should support more configurable classfile targets, including CLDC 1.0, CLDC 1.1 and possibly JSR14 (generics experimentation for 1.4 VMs).
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Drive quick navigation support to the next level</strong>
Use the new SWT custom rendering support to show the items as links, show additional info (e.g. Javadoc), allow to open Quick views from everywhere (e.g. from the Package Explorer or Outline view) and eventually offer a context menu (investigation item). [JDT Text]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>New Annotation Processing API (JSR 269)</strong>
The initial implementation of APT used a provisional API from Sun. Java 6 introduced a standard API. APT should implement this.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improve integration of annotation processing tooling</strong>
APT integration should improve in various areas, including editor reconciling and codeassist. 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 modelled using working copies, and provide the same level of functionality of JDT when autobuild is turned off. Also, on codeassist front, we want to provide a simple API for processors to supply domain specific knowledge to completions inside annotation values.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improve compiler fault-tolerance</strong>
Missing types can greatly deteriorate compiler output by producing too many secondary errors, surface suboptimal DOM bindings, or even abort entire compilation process when missing types are referenced from required classfiles. We should investigate ways to improve this situation, remembering that the APT Mirror API requires that bindings are still presented even in the presence of missing types.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Enhance launching support</strong>
Simplify the launch experience for novice users. Introduce single click context sensitive launching and investigate launching based on content types at different levels in the resource hierarchy. Allow launch configurations to be managed via a resource's properties. Investigate launch configuration templates allowing common launch settings to be shared among a group configurations.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<h2>Darin's Item</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Support for JavaSE6 debug features</strong>
Implement new JavaSE6 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, breakpoints for monitor acquisition and release, access to the constant pool, and improved class prepare event filtering. [Theme: Appealing to the Broader Community] [JDT Debug]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>SWT Launching/Building Support</strong>
<em>(No agreement between debug, jdt, and pde on this one)</em>Simplify SWT launching by replacing the 'SWT Application' launch configuration type with an 'SWT classpath container'. The SWT classpath container can be added to a project's build path to pick up the appropriate SWT libraries at build time and is associated with required native libraries for run and debug support. Running and debugging SWT applications would work with the 'Java Application' launch configuration type. Existing SWT launch configurations should be converted to Java launch configurations via the launch configuration migration support. [Theme: Appealing to the Broader Community, Simple to Use][JDT UI, JDT Debug]
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</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>
<h2>Jeff and Wassim's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<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,
bundle produced by third parties and non-bundlized code libraries. Tooling in support
of checking and managing the evolution of component and package version numbers
will also be supplied.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Bundle/Module Development Tools</strong>
In 3.1 and 3.2 PDE made gigantic strides in the area of 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 and is
included in Java 6, PDE will be there to provide developer support. 3.3
will also see the need for tooling around OSGi Declarative Services and
the new application model.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improved Launching Support</strong>
PDE is the premier IDE-based OSGi bundle development environment however it currently only supports
launching of Equinox frameworks. The PDE launching capabilities will be enhanced to allow
others to add in customized launch mechanism and we will work with communities such as Felix
and Knopflerfish to include support for launching their frameworks. This support will also facilitate
support for launching normal Java applications where the application classpath is
based on the dependencies specified in bundle markup. PDE will also include support for "hot launching"
whereby an already running OSGi framework is reconfigured to match the launch configuration
being invoked. This enables users to test of code changes without going through potentially costly
restart procedures.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Target Provisioning</strong>
Currently, users wanting to use 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. As part of this the mechanism by which source is
packaged, acquired and looked up will be reviewed and streamlined.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<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.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<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 prebuilt 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.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>User-Assistance Tooling</strong>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=146988
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
</blockquote>
<h4>Deferred Items (Eclipse PDE project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse PDE project.)</p><p>
</p><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><em>Overall Theme: Components</em></h4>
Enhance Eclipse's use of and support for software components. This covers
everything from component programming models such as Declarative Services
and Spring to API tools to incremental building to fine-grained function delivery.
<h4>Committed Items (Equinox project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Equinox project)</h4>
<blockquote>
<h2>Jeff's Items</h2>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong></strong>
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<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.
Users 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/needed plugins. To make this easier we will revise the
feature/grouping structure to capture more independent and re-usable components.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Improved support for provisioning</strong>
Update Manager has evolved quite slowly while the world around it has
advanced quite quickly. New usecases (RCP, Equinox, server side, ...) and
technlogies (e.g., OSGi) have come to play in Eclipse but Update Manager
has not been enhanced to support or exploit these changes. In 3.3 we
will undertake a significant effort to rework the Eclipse Update Manager
support to enhance workflows, efficiencies (download and disk footprint),
support fine-grained discovery and acquisition of function and facilitate
integration with a wide range of repositories. This effort also includes work
to tool the new provisioning mechanisms.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Complete Update Support</strong>
Most but not all of Eclipse is updateable. The so-called "root files"
(e.g., startup.jar, eclipse.exe) typically cannot be updated in a reasonable
fashion. In 3.3. we will make all aspects of Eclipse updatable. Gone will
be the days of not being able to update from one release to the next.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<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 manageabilty of
the system (e.g., simplifying and clarifying the shutdown process0 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.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Runtime Refactoring</strong>
In 3.2. we were able to refactor the runtime to split out the registry,
jobs, content types, preferences, etc. Unfortunately we were not able to
complete the job and the Runtime plugin itself still includes non-trivial
function around the notion of Eclipse applications and various static
helpers (e.g., Platform). This introduces unfortunately broad couplings
between the former runtime elements and limits the usability of these
independent pieces in various scenarios. Once the application model is
split out and the Platform helper methods are replaced with a simple to
use component discovery mechanism, the Runtime plugin will be a shell or
facade needed for legacy support.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Component Programming Models</strong>
Eclipse has successfully put Java components on the map and made them
useful/relevant to normal programmers. The decoupling of systems into
components has raised the need for composition coding patterns.
Traditional Eclipse uses the extension registry. Traditional OSGi uses
the service registry. Both have their benefits and drawbacks. On the
whole, component programmers are not particularly well served. The OSGi R4
platform specification introducted the notion of Declarative Services which
address some of these concerns. Outside of Eclipse/OSGi, component containers
such as Spring have attracted significant interest. To better facilitate
the creation and composition of components we will investigate programming
models using declarative services, Spring and other relevant component
mechanisms with a view to widespread use in Eclipse.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>OSGi R5 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 JSR277, JSR291 and JSR232) this participation has never been more important.
In addition to promoting Eclipse usecases and the evolution of these standards
benefits Eclipse, there are a number of gaps in the OSGi specifications that
Eclipse is currently filling in specific ways and should be addressed in R5.
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, ... The Equinox team will continue
their active participation in these specification processes and keep Eclipse
on the leading edge of Java componentization.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Server side</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 usecases
presented by various other Eclipse projects that are adopting Eclipse on the
server (e.g., ECF, ECP, Corona).
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Security</strong>
Towards the middle/end of the 3.2 cycle the Equinox Security incubator started
to produce secured versions of the base RCP plugins. Various tests and benchmarks
were run to show the general feasibility of the approaches. With the proof of
concept complete, we need to progress to understanding what it means for the
Eclipse team to write and maintain secure code and then look to secure a relevant
set of plugins using the tools and techniques developed in the incubator.
Similarly, various people have been working on login and authentication support.
In 3.3. we should finalize this work and actually include full support for these
vital parts of the RCP story.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Overrides</strong>
Component development and use is frought with producer/consumer problems. Component
producers implement solutions that address a number of usecases and scenarios but
inevitably consumers come up with additional, sometimes quite divergent requirements.
As such, the ability of component consumers to "override" or replace metadata
specifications in the components they are consuming allows them to better integrate
these components into their situations. Further it has the potential to free component
producers and allow them to define default values or settings where previously such
settings were clearly a violation of their perspective. This is done with the
undersanding that consumers are free to override such decisions. Usecases range
from tweaking version ranges when bugs and patches are discovered to overriding
extension contributions, capability definitions, platform filters, ...
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> new)
<strong>Monitoring</strong>
Historically the Runtime team has developed and maintained a set of "Core Tools" that allow
developers to inspect and monitor some of the inner workings of a running Eclipse system. These
tools have fallen behind the current technology and usecases at a time when they are of increasing
importance. In 3.3 the tools will be updated and enhanced to include remote monitoring capabilities
and deeper inspection of a running Equinox-based system.
[]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXX"><font color="red">XXXXX</font></a>)
[Theme: ]</p>
</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><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 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 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">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.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/1.5</div>
</td>
</tr>
<tr>
<td>org.eclipse.jdt.junit.runtime</td>
<td>
<div align="center">1.4/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/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.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.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>