Google Git
Sign in
eclipse / www.eclipse.org / eclipse / 514e744387a4548b2d89fec6cac7f119115e816d / . / development / eclipse_project_plan_3_1.html
blob: 89330f3943ec91dc6a8ce6ebdb590ad469bab4fa [file] [log] [blame]
<!-- saved from url=(0022)http://internet.e-mail -->
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="Author" content="Eclipse Project PMC">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Eclipse Project 3.1 Plan (Final)</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>
<h1>Eclipse Project<br>
3.1 Plan (Final)</h1>
<p>Last revised 16:02 EDT June 10, 2005 (<img border="0" src="new.gif" width="12" height="12">
marks interesting changes since the <a href="eclipse_project_plan_3_1_20050413.html">draft
of Apr. 13, 2005</a>)<br>
<br>
<i>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to the </i><a href="mailto:eclipse-dev@eclipse.org">eclipse-dev@eclipse.org</a>
<i>developer mailing list.</i></p>
<p>This document lays out the feature and API set for the next feature release
of Eclipse after 3.0, designated release 3.1.
<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>
</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 PMC) post plans in an embryonic form and revise them
throughout the release cycle.
<p>The first part of the plan deals with the important matters of release
deliverables, release milestones, target operating environments, and
release-to-release compatibility. These are all things that need to be clear for
any release, even if no features were to change.&nbsp;
<p>The remainder of the plan consists of plan items for the three projects under
the Eclipse top-level project. Each plan item covers a feature or API that is to be added to
Eclipse, or some aspect of Eclipse that is to be improved. Each plan item has
its own entry in the Eclipse bugzilla database, with a title and a concise
summary (usually a single paragraph) that explains the work item at a suitably
high enough level so that everyone can readily understand what the work item is
without having to understand the nitty-gritty detail.
<p>Not all plan items represent the same amount of work; some may be quite
large, others, quite small. Some plan items may involve work that is localized
to a single Platform component; others may involve coordinated changes to
several components; other may pervade the entire Platform. Although some plan
items are for work that is more pressing that others, the plan items appear in
no particular order.
<p>With the previous release as the starting point, this is the plan for how we
will enhance and improve it. Fixing bugs, improving test coverage,
documentation, examples, performance tuning, usability, etc. are considered routine
ongoing maintenance activities and are not included in this plan unless they
would also involve a significant change to the API or feature set, or involve a
significant amount of work. The intent of the plan is to account for all interesting feature work.
<p>The current status of each plan item is noted:
<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>
<li><b>Rejected</b> plan item - Plan items that were proposed but judged
unworkable are marked as rejected plan items, with an accompanying summary
of why they were dismissed. Keeping track of rejected items avoids repeating
the discussion.</li>
</ul>
<h2><a name="Deliverables"></a>Release deliverables</h2>
<p>The release deliverables have the same form as previous releases, namely:
<ul>
<li>Source code release for Eclipse Project, available as versions tagged
&quot;R3_1&quot; in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS
repository</a>.</li>
<li>Eclipse Project SDK (includes runtime binary and SDK for Platform, JDT,
and PDE) (downloadable).</li>
<li>Eclipse Platform runtime binary and SDK distributions (downloadable).</li>
<li>Eclipse RCP runtime binary and SDK distributions (downloadable).</li>
<li>JDT runtime binary and SDK distributions (downloadable).</li>
<li>PDE runtime binary and SDK distributions (downloadable).</li>
<li>Eclipse SDK Examples (downloadable).</li>
<li>SWT distribution (downloadable).</li>
</ul>
<h2><a name="Milestones"></a>Release milestones</h2>
<p>Release milestone occurring at roughly 6 week intervals exist to facilitate
coarse-grained planning and staging. The milestones are:</p>
<ul>
<li>Friday Aug. 13, 2004 - Milestone 1 (3.1 M1) - stable build</li>
<li>Friday Sep. 24, 2004 - Milestone 2 (3.1 M2) - stable build</li>
<li>Friday Nov. 5, 2004 - Milestone 3 (3.1 M3) - stable build</li>
<li>Friday Dec. 17, 2004 - Milestone 4 (3.1 M4) - stable build</li>
<li>Friday Feb. 18, 2005&nbsp; - Milestone 5 (3.1 M5) - stable build</li>
<li>Friday Apr. 1, 2005 - Milestone 6 (3.1 M6) - stable build - API complete
- API freeze</li>
<li>Friday May 13, 2005 - Milestone 7 (3.1 M7) - stable build - feature complete
- development freeze - lock down and testing begins</li>
</ul>
<p><img border="0" src="new.gif" width="12" height="12"> Lock down and testing
then begins with M7, and progress through a series of test-fix passes against
candidates releases. Release candidate builds are planned as follows (M7 is
release candidate 0):</p>
<ul>
<li>Friday May 27, 2005 - Release Candidate 1 - (3.1 RC1)</li>
<li>Friday June 10, 2005 - Release Candidate 2 - (3.1 RC2)</li>
<li>Friday June 17, 2005 - Release Candidate 3 - (3.1 RC3)</li>
<li>Friday June 24, 2005 - Release Candidate 4 - (3.1 RC4)</li>
</ul>
<p> Depending on the circumstances, we may add additional release candidate builds
or fine-tune the schedule. The 3.1 release is targeted for the week of June
27, 2005. See the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-project-home/plans/3_1/freeze_plan.html">Eclipse
3.1 Endgame Plan</a> for further details. All release deliverables will be available
for download as soon as the release has been tested and validated in the target
operating configurations listed below.</p>
<h2><a name="TargetOperatingEnvironments"></a>Target Operating Environments</h2>
<p>In order to remain current, each Eclipse release targets reasonably current
versions of the underlying operating environments.</p>
<p>Most of the Eclipse SDK is &quot;pure&quot; Java™ code and has no direct
dependence on the underlying operating system. The chief dependence is therefore
on the Java 2 Platform itself. The 3.1 release of the Eclipse Project is written
and compiled against version 1.4 of the Java 2 Platform APIs, and targeted to
run on version 1.4 of the Java 2 Runtime Environment, Standard Edition.</p>
<p>There are many different implementations of the Java 2 Platform running atop
a variety of operating systems. We focus Eclipse testing on a handful of popular
<span class="header">combinations of operating system and Java 2 Platform; these
are our <em>reference platforms</em>. Eclipse undoubtedly runs fine in many
operating environments beyond the reference platforms we test. However, since we
do not systematically test them we cannot vouch for them. Problems encountered
when running Eclipse on non-reference platform that cannot be recreated on any
reference platform will be given lower priority than problems with running
Eclipse on a reference platform.</span></p>
<p>Eclipse SDK 3.1 is tested and validated on the following reference platforms
(this list is updated over the course of the release cycle):</p>
<table width="821" border="1">
<tr bgcolor="#CCCCCC">
<th colspan="4">
<div align="center">
<b><font size="+1">Eclipse Reference Platforms</font></b>
</div>
</th>
</tr>
<tr>
<td width="205"><b>Operating system</b></td>
<td width="76"><b>Processor architecture</b></td>
<td width="59"><b>Window system</b></td>
<td width="453"><b>Java 2 Platform</b></td>
</tr>
<tr>
<td width="205">Microsoft Windows XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">Sun Java 2 Standard Edition, version 1.4.2_08 for Microsoft
Windows</td>
</tr>
<tr>
<td width="205">Microsoft Windows XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453"> <p>IBM 32-bit SDK for Windows, Java 2 Technology Edition,
Version 1.4.2 SR1a</p>
</td>
</tr>
<tr>
<td width="205">Microsoft Windows XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453">Sun Java 2 Standard Edition 5.0 Update 2 for Microsoft Windows</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux WS 3</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">Sun Java 2 Standard Edition, 1.4.2_08 for Linux x86</td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux WS 3</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology
Edition, Version 1.4.2 SR1a</td>
</tr>
<tr>
<td width="205">SLES 9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">Sun Java 2 Standard Edition, version 1.4.2_08 for Linux x86</td>
</tr>
<tr>
<td width="205">SLES 9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology
Edition, Version 1.4.2 SR1a</td>
</tr>
<tr>
<td width="205">Sun Solaris 8</td>
<td width="76">SPARC</td>
<td width="59">Motif</td>
<td width="453">Sun Java 2 SDK, Standard Edition, 1.4.2_08 for Solaris SPARC</td>
</tr>
<tr>
<td width="205">HP HP-UX 11i</td>
<td width="76">hp9000<br>
PA-RISC</td>
<td width="59">Motif</td>
<td width="453"><p>HP-UX SDK for the Java 2 platform, version 1.4.2.07 for
hp9000 PA-RISC</p></td>
</tr>
<tr>
<td width="205" height="21">IBM AIX 5L Version 5.2</td>
<td width="76">PowerPC</td>
<td width="59">Motif</td>
<td width="453"><p>IBM 32-bit SDK for AIX, Java 2 Technology Edition, Version
1.4.2 SR1a</p>
</td>
</tr>
<tr>
<td width="205">Apple Mac OS X 10.3</td>
<td width="76">PowerPC</td>
<td width="59">Carbon</td>
<td width="453">Java 2 Standard Edition
1.4.2 for Mac OS X</td>
</tr>
</table>
<p>Although untested, Eclipse should work fine on other OSes that support the
same window system. For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT
HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux
systems: version 2.2.1 of the GTK+ widget toolkit and associated librares (GLib,
Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on other Linux
systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.</p>
<p>An early access version of Eclipse is also available for 64-bit Linux GTK.
Testing has been limited to early access 64-bit J2SEs running on 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.1 on Windows or Linux
can be used cross develop QNX applications. (Eclipse 3.1 is unavailable on QNX
because there is currently no 1.4 J2SE for QNX.)</p>
<h4>Internationalization</h4>
<p>The Eclipse Platform is designed as the basis for internationalized products.
The user interface elements provided by the Eclipse SDK components, including
dialogs and error messages, are externalized. The English strings are provided
as the default resource bundles.</p>
<p>Latin-1 locales are supported by the Eclipse SDK on all of the above
operating environments; DBCS locales are supported by the Eclipse SDK on the
Windows, GTK, and Motif window systems; BIDI locales are supported by the
Eclipse SDK only on Windows operating environments.
<p>The Eclipse SDK supports GB 18030 (level 1), the Chinese code page standard,
on Windows XP and 2000, and Linux.
<p>German and Japanese locales are tested.</p>
<h4>BIDI support</h4>
<p><img border="0" src="new.gif" width="12" height="12"> SWT fully supports BIDI
on Windows (only). On Linux GTK, SWT supports entering and displaying BIDI text.
The widget orientation of JFace windows defaults appropriately in BIDI locales
on all platforms.</p>
<p>The Eclipse SDK is a development environment targeted at technical professionals
- not an end user application. However, the Eclipse SDK tools will permit technical
professionals who are working in English to build Hebrew/Arabic end user Java
programs which are themselves not based on the Eclipse SDK. The BIDI support
in the Eclipse SDK allows a Java programmer to work with BIDI strings, code
comments, etc. but the Eclipse SDK itself is not designed to be localized for
BIDI locales and its widget orientation can not be changed.</p>
<h2><a name="Compatibility"></a>Compatibility with Previous Releases</h2>
<h3>Compatibility of Release 3.1 with 3.0</h3>
<p>Eclipse 3.1 will be compatible with Eclipse 3.0.</p>
<p><b>API Contract Compatibility:</b> Eclipse SDK 3.1 will be upwards
contract-compatible with Eclipse SDK 3.0 except in those areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_1_porting_guide.html" target="_top"><em>Eclipse
3.1 Plug-in Migration Guide</em></a>. Programs that use affected APIs and extension points
will need to be ported to Eclipse SDK 3.1 APIs. Downward contract compatibility
is not supported. There is no guarantee that compliance with Eclipse SDK 3.1
APIs would ensure compliance with Eclipse SDK 3.0 APIs. Refer to <i><a href="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.1 will be upwards
binary-compatible with Eclipse SDK 3.0 except in those areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_1_porting_guide.html" target="_top"><em>Eclipse
3.1 Plug-in Migration Guide</em></a>. Downward plug-in compatibility is not supported.
Plug-ins for Eclipse SDK 3.1 will not be usable in Eclipse SDK 3.0. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that
maintain binary compatibility.
<p><b>Source Compatibility:</b> Eclipse SDK 3.1 will be upwards
source-compatible with Eclipse SDK 3.0 except in the areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_1_porting_guide.html" target="_top"><em>Eclipse
3.1 Plug-in Migration Guide</em></a>. This means that source files written to use Eclipse
SDK 3.0 APIs might successfully compile and run against Eclipse SDK 3.1 APIs,
although this is not guaranteed. Downward source compatibility is not supported.
If source files use new Eclipse SDK APIs, they will not be usable with an
earlier version of the Eclipse SDK.
<p><b>Workspace Compatibility:</b> Eclipse SDK 3.1 will be upwards
workspace-compatible with Eclipse SDK 3.0 unless noted. This means that
workspaces and projects created with Eclipse SDK 3.0 can be successfully opened
by Eclipse SDK 3.1 and upgraded to a 3.1 workspace. This includes both hidden
metadata, which is localized to a particular workspace, as well as metadata
files found within a workspace project (e.g., the .project file), which may
propagate between workspaces via file copying or team repositories. Individual
plug-ins developed for Eclipse SDK 3.1 should provide similar upwards
compatibility for their hidden and visible workspace metadata created by earlier
versions; 3.1 plug-in developers are responsible for ensuring that their
plug-ins recognize 3.1, 3.0, 2.1, and 2.0 metadata and process it appropriately.
User interface session state may be discarded when a workspace is upgraded.
Downward workspace compatibility is not supported. A workspace created (or
opened) by a product based on Eclipse 3.1 will be unusable with a product based
an earlier version of Eclipse. Visible metadata files created (or overwritten)
by Eclipse 3.1 will generally be unusable with earlier versions of Eclipse.
<p><b>Non-compliant usage of API's</b>: All non-API methods and classes, and
certainly everything in a package with &quot;internal&quot; in its name, are
considered implementation details which may vary between operating environment
and are subject to change without notice. Client plug-ins that directly depend
on anything other than what is specified in the Eclipse SDK API are inherently
unsupportable and receive no guarantees about compatibility within a single
release much less with an earlier releases. Refer to <i><a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">How
to Use the Eclipse API</a></i> for information about how to write compliant
plug-ins.
<h2>Themes and Priorities</h2>
<p><strong> </strong>The changes under consideration for the next release of Eclipse
Platform, JDT, and PDE address major themes identified by the Eclipse Requirements
Council. (The theme synopses here are cut down versions of the ones in Eclipse
Requirements Council: Themes and Priorities dated Dec. 15, 2004 - <a href="http://www.eclipse.org/org/councils/20041215EclipseTPFinalDraft.pdf">pdf)</a>.
The themes are not in priority order.</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 Platform. The Eclipse Platform 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><b>Rich Client Platform </b>- The Eclipse RCP is a Java-based application
framework for the desktop. Building on the Eclipse runtime and the modular
plug-in story, it is possible to build applications ranging from command line
tools to feature-rich applications that take full advantage of SWT's native
platform integration and the many other reusable components that the Eclipse
platform provides. This theme includes work to enhance the RCP, and to provide
PDE support for developing and deploying RCP-based applications.</li>
<li><b>Simple to Use</b> - The Eclipse platform needs to not only provide the
features that advanced users demand, but also be something that most users
find simple to use. This theme includes ease-of-use reviews of existing features,
and work that helps make Eclipse-based products simple to use for users with
widely-varying backgrounds and skill sets.</li>
<li><b>Appealing to the Broader Community</b> - This theme includes work that
grows deeper roots into the various OS-specific communities, spreads Eclipse
to additional operating environments, and builds bridges to other open source
communities and vertical market segments</li>
</ul>
<p>In addition, there are a few important Eclipse Platform improvements that do
not naturally fit into any of the above themes.</p>
Each of the 3 projects under the Eclipse top-level project is covered in its
own section:
<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>
</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.
<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><strong>Mapping logical views to physical files on disk.</strong> In some
cases, multiple distinct objects happen to be stored in a single file, like
an archive. Conversely, in other cases, something that is logically a single
object is stored across multiple files. This discrepancy between logical and
physical creates problems for common operations such as searching, comparing,
and versioning, which need to work in the physical realm. Eclipse should support
some way of mapping between a logical view and the physical organization of
files on disk. [Platform Core, Platform UI, Team] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80396">80396</a>
) [Theme: Design for Extensibility]<em> <img src="ok.gif" width="12" height="12">
Work completed (Follow-on work is planned for the next release.)</em></p>
<p><strong>Large-scale workspaces.</strong> Some large customers have workspaces
containing several hundred projects. Scoped builds (added in 3.0) were a step
in the right direction towards making these workable. Eclipse needs to provide
appropriate support for large workspaces and working sets, and ensure that
everything scales properly. [Platform Core; Platform UI; JDT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71128">71128</a>)
[Theme: Scaling Up] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Process improvements wrt performance.</b> For 3.1 we should get a firm
grip on speed and space performance. To do this we should (1) identify which
aspects are critically important performance-wise; (2) establish benchmarks
to quantify performance; and (3) look at ways to improve performance. By its
nature, it's hard to say in advance what kind of improvements we'll be able
to achieve, making it difficult to make performance improvements a release
deliverable. Instead, what we need to do for 3.1 is commit to track performance
from this point on. We should carry out performance reviews (1) and create
benchmarks (2) for every component, and for any critical aspects that span
components. Even if we cannot find ways to make significant performance gains
(3), the benchmarks are still critical to Eclipse's success to prevent backsliding
in the future. The work item is to improve our process with respect to performance.
The deliverables are the automated performance tests, the build process that
collects and publishes performance data covering all critical aspects of Eclipse,
and the commitment to leverage this data to monitor speed and space performance
as part and parcel of developing Eclipse. [All Eclipse components] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71123">71123</a>)
[Theme: Scaling Up] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Overhaul preferences.</b> The way that Eclipse deals with preferences
should be improved. The workbench presentation of preferences generally uses
a component-oriented hierarchy, which is not always the best choice for users.
The UI should present preferences in such a way that users can readily discover
them. Some preference settings have scopes (e.g., workspace-wide vs. per project).
The UI should help the user to visualize these scopes. For team-wide uniformity,
some preferences settings (e.g., compiler options) need to be shared (or imposed)
across teams. The UI should also facilitate this. [Platform Core; Platform
UI; Text; JDT UI; JDT Core] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71124">71124</a>)
[Theme: Simple to use] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Improve action contributions.</b> Simplify the programming model for contributing
menu and toolbar items to the workbench (and their corresponding appearance
and behavior). Improve control over menu definition and item ordering. Allow
the selected object in a view to override an action, e.g., Rename menu item
on Java element in navigator view resolves to JDT refactoring rename instead
of basic file rename. Maintain a strong separation between a command, its
handler(s) and its placement(s) in the UI. [Platform UI; Platform Text; JDT
UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36968">36968</a>)
[Theme: Design for Extensibility] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Scalability.</b> In cases where either the target machine is resource-constrained,
or the number of plug-ins is large, or the size of the workspace is large,
the scalability of the Eclipse Platform is especially important. The work
involves identifying problematic areas and making changes to improve the scalability.
[All components] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80129">80129</a>)
[Theme: Scaling Up] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Improve capabilities.</b> Eclipse 3.0 introduced the notion of capabilities
and provided categories for grouping related capabilities. These capabilities
are used to simplify the UI by hiding functionality that is not currently
relevant to the user. This plan item is to improve this support. The missing
features center around a product's ability to successfully support higher-level
notions (like user roles) and control when and how capabilities get enabled.
[Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80130">80130</a>)
[Theme: Simple to use] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>Ant editor improvements.</strong> Provide the Ant editor with comparable
functionality to the Java editor with regard to folding, hyperlink navigation,
open declaration, marking occurrences, show external documentation, refactoring,
etc. [Ant] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80135">80135</a>)
[Theme: Simple to use] <em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Breakpoint improvements. </strong>Simplify debugging with lots of
breakpoints: provide different ways to group and organize breakpoints so that
they can be enabled/disabled as a unit. [Debug] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80136">80136</a>)
[Theme: Scaling Up] <em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Generalized undo support.</b> The Platform should define a common command
processing framework in order to provide a workbench-wide undo/redo facility.
[Platform UI; Platform Text; JDT UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80137">80137</a>)
[Theme: Design for Extensibility] <img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Content types.</b> The algorithm that the Eclipse Platform uses to determine
which editor to open is based on the file's name and simple matching rules.
In many cases like XML files this simple approach is not sufficient. The Platform
needs to provide a more robust and scalable solution based on the content
of the resource. [Platform UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>)
[Theme: Design for Extensibility] <img src="ok.gif" width="12" height="12">
Work completed</em></p> <p><b>Add critical performance instrumentation.</b> Add support for monitoring
performance and detecting problems in performance critical aspects of the
Eclipse Platform. Potential critical areas to monitor include the times to:
start up a plug-in, open an editor, display a menu, switch perspectives, process
an SWT event, process a resource change event, etc. [Platform UI; Platform
Core; SWT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80138">80138</a>)
[Theme: Scaling up] <em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Initial user experience improvements.</b> Support for Welcome content
will be enhanced by a number of improvements: authoring of welcome content
will be made easier by providing easy preview of the resulting pages when
all the content is composed; whenever possible, help documents will be shown
in place to reduce the need to leave the Welcome context; transition to workbench
will be made less abrupt with various degrees of welcome still present for
the user to return; support for welcome in sophisticated stacked products
will be enhanced. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80139">80139</a>)
[Theme: Simple to use] <em><img src="ok.gif" width="12" height="12"> Work
completed</em></p>
<p><b>Help search enhancements.</b> Search will be enhanced in a number of ways.
Add the ability to search the web in addition to local documentation, and
to collate results from multiple search engines queried in parallel. Improve
the presentation of search by exposing Help searches in wizard UI panes, and
by making search pervasive in the workbench. [Help, Platform UI, Search] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80131">80131</a>)
[Theme: Design for Extensibility; Simple to Use] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><b>Pervasive context help pane.</b> The Platform should provide a reusable
pane to show context help for the currently active context. The pane can be
used in various places, including views and wizard dialogs. The pane shows
additional help on the current context, links to help topics about it, and
a quick search entry. [Help, Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80143">80143</a>)
[Theme: Simple to use] <em><img src="ok.gif" width="12" height="12"> Work
completed</em></p>
<p><strong>RCP performance.</strong> Startup time and total space requirements
are key elements in the viability of Eclipse as an RCP. In the 3.1 cycle we
will focus on these two performance characteristics with the particular goals
of: reducing space required internal data structures (e.g., framework state,
extension registry, ...); streamlining the startup execution to get to the
application code faster; and providing basic support for space-efficient resource
bundles. [Platform Core] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80145">80145</a>)
[Theme: Rich Client Platform; Scaling Up] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>RCP infrastructure.</strong> There are various improvements to the
RCP infrastructure to better support a widening range of uses, including:
improve support for preconfigured installs; and improve support for API declaration/consumption.
Additionally, all RCP-related plug-ins will be updated to use only classes
in the J2ME CDC/Foundation profile. [Platform Core; Platform UI; Update; Help]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80146">80146</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>OSGi. </strong>Eclipse 3.1 will include a compliant implementation
of the upcoming OSGi Platform R4 specification. We will also increase the
flexibility of the adaptor structure of the OSGi framework in order to make
it easier to use the Eclipse OSGi implementation on its own. [Platform Core]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80147">80147</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>Dynamic plug-ins.</strong> In Eclipse 3.0 it became possible to install
and remove plug-ins without restarting the system. In practice this is a cooperative
effort requiring the rest of the plug-ins in the system to respond correctly
to the changes. Work will be done to increase the runtime support for making
plug-ins dynamic-aware, including annotating plug-ins with their dynamic characteristics,
changing the registry data structure to use light-weight handles, and provide
support for tracking key objects. Other RCP plug-ins will be updated to use
these mechanisms. Also, develop reusable coding structures and guidelines
for writing dynamic-aware plug-ins. [Platform Core; Platform UI; Platform
Text; Update; Help] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80148">80148</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>JNLP Support.</strong> It is convenient to be able to launch a Java-based
application from a web browser. There are various technical issues with launching
Eclipse using Java Web Start (JNLP). We will ensure that the simple forms
of JNLP-based deployment are supported, and will investigate supporting more
advanced solutions that could provide a higher level of integration between
the Eclipse component model and that of JNLP. [Platform Core] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80149">80149</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>Support for launcher branding.</strong> A key step in producing an
RCP-based product is creating the launcher the user uses to run the product.
As a minimum it should have a product-specific name and icon. Currently, constructing
such a launcher requires a C compiler and other OS-specific tools. We will
investigate providing template launchers which can be instantiated by PDE
when assembling a product for a given OS. [SWT; PDE] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80150">80150</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>Ant debugger.</strong> Provide an integrated debugger for Ant build
files. [Ant] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80151">80151</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Provide better text editor support for RCP.</strong> The following
functions were added: pluggable spell checking, URL detection and handling.
[Platform Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80154">80154</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
</blockquote>
<h4>Proposed Items (Eclipse Platform project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse Platform project)</h4>
<blockquote>
<p><b>Embedding editors and views.</b> Various plug-ins encounter problems when
trying to embed editors or views within other workbench parts. For example,
the current compare infrastructure requires a plug-in to create a separate
text editor for viewing changes between files. This is due to a limitation
in the workbench that prevents editors from being embedded inside views or
other controls. As a consequence, the compare editor's nested editors don't
support the full set of features provided by the corresponding real content-type-specific
editor. This represents a major usability problem: the user must switch to
the real editor to make changes and then return to the compare view to review
the changes. Eclipse should be more flexible in the ways various editors can
be used and reused. Improve the UI component model to support nesting of workbench
parts. Reduce coupling of parts to particular locations in the workbench,
allowing for more flexible UI configurations. [Platform UI, Compare, Platform
Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71125">71125</a>)
[Theme: Design for Extensibility]</p>
<p><strong>Security.</strong> Support ongoing work in Equinox investigating
security. This covers items such as enabling Java 2 security managers, plug-in
signing, techniques and mechanisms for authentication and authorization and
credential stores as well as end-to-end security of the Platform install.
[Platform Core; Platform Update] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37692">37692</a>)
[Theme: Rich Client Platform]</p>
<p><b>Team policies.</b> Teams of developers working together have special needs
for ensuring the integrity and consistency of their collective work. For example,
they may have policies for things like source file naming, code formatting,
or bug report number for change tracking. Eclipse should enable tools that
help achieve that integrity and consistency. Eclipse should provide more access
points so that complex policies can be suggested, checked, or enforced. [Platform
Core; Team] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71126">71126</a>)
[Theme: Enterprise Ready]</p>
<p><strong>Provide better text editor support for RCP.</strong> The list of
functions to add will grow over time. The initial set includes: annotation
presentation and navigation, user assigned colors and fonts, enable spell
checking in non-Java editors, user defined persistent folding, quick diff,
templates. [Platform Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80154">80154</a>)
[Theme: Rich Client Platform] </p>
<p><b>Macro recording and playback.</b> Add a mechanism for recording a sequence
of user interface interactions, storing then in a file, and playing them back
at a later time. File playback will be made available as an action for the
benefit of cheat sheets and active help. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80140">80140</a>)
[Theme: Simple to use]</p>
<p><b>Improve cheat sheet authoring.</b> The goal is to better support authoring
of cheat sheets by non-programmers by allowing actions to be recorded as macros
to handle 'do it for me' step actions. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80142">80142</a>)
[Theme: Simple to use]</p>
<p><b>Enhancements for supporting new users.</b> Following on from the work
done in Eclipse 3.0, we want to further improve the way Eclipse feels to new
users. For example: support for templates (to create projects that do something
useful) as well as a set of templates that ship with Eclipse SDK; support
for samples (enhancing sample support shipped in 3.0 and making it API); safe
mode (a constrained mode of running the workbench - 'training wheels' - where
capabilities are restricted in order to prevent common early mistakes); simpler
workspace chooser (where do you want your work saved?); more usable perspective
chooser with short description, a small image that shows the general perspective
layout, perspective groups by role e.g. Java Development. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80132">80132</a>)
[Theme: Simple to use]</p>
<p><b>Help system improvements.</b> A number of improvements would be added
to the current help system to address the current problems and make help more
useful. Improvements include: Allow help content to appear embedded in various
places of the workbench (welcome, cheat sheets, help view) as a way to avoid
problems caused by having all Help presented in a separate window (this would
also entail some rework of the Tasks sections of the Eclipse help books to
make them suitable for presentation in a narrow window).&nbsp;Provide a hook
from error dialogs into help. [Help] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80141">80141</a>)
[Theme: Design for Extensibility; Simple to Use]</p>
</blockquote>
<h4>Rejected Items (Eclipse Platform project)</h4>
<blockquote>
<p><strong>Concurrency support for debuggers.</strong> Many debug architectures
require communicating with a remote debug target. The debug user interface
needs to be robust in the face of latent and unreliable connections. To avoid
blocking the user interface, the debug platform will use background jobs to
perform operations and communicate with debuggers. [Platform Debug, JDT Debug]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80152">80152</a>)
[Theme: Design for Extensibility]</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><b>Add support for J2SE 5 features. </b>J2SE 5 (also known as JDK 1.5 &quot;Tiger&quot;)
shipped in September 2004. This release contains <a href="http://download.oracle.com/javase/1.5.0/docs/guide/language/index.html">new
Java language features</a>, including generic types, typesafe enumerations,
autoboxing, enhanced for loops, static imports, varargs, and annotations.
Supporting these new language and compiler features requires major changes
to the Eclipse Java compiler, to JDT Core APIs, to JDT UI, and to JDT Debug.
Eclipse should contain full support for developing Java programs that use
the new language features, including code assist, quick fixes, new wizards,
source actions, and refactorings. There should also be quick assists and refactorings
for migrating existing Java code to the new language constructs, including
inferring type parameters for Collections, and converting simple for loops
to use the enhanced for loop. [JDT Core, JDT UI, JDT Text, JDT Debug] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36938">36938</a>)
[Theme: Appealing to the Broader Community] <em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Improved compiler checking.</strong> Add support for detecting references
to internal classes; add warnings about missing declarations of serialVersionUID,
incomplete enum switches, boxing and unboxing conversions, and type parameter
declaration hiding. [JDT Core] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80155">80155</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Improve support for externalized strings.</strong> Provide a separate
properties file editor, and enhance the Java editor to display the value of
and navigate from an NLS key in code and the corresponding entry in the properties
file. [JDT Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80156">80156</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Debugger usability improvements.</strong> Integrate monitor locks
into the debug view, show variable values inline, support hyperlink-style
navigation from the text of any stack trace. [JDT Debug; Platform Debug] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80158">80158</a>)
[Theme: Simple to use] <em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><strong>Import/export of Ant build files.</strong> Using information from
the javac task in an existing Ant build file, create a Java project, import
the source files, and configure the project's build class path. Conversely,
from an existing Java project generate an Ant build file that will compile
the project's source files. [JDT UI; Ant] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80159">80159</a>)
[Theme: Enterprise Ready] <em><img src="ok.gif" width="12" height="12"> Work completed</em></p>
<p><b>Improve program manipulation infrastructure.</b> Parts of the Java model
are still implemented in terms of the deprecated JDOM, an early precursor
of the AST facility. JDT should move to an AST-based implementation of the
Java model. All source and refactoring operations should be rewritten to use
common program manipulation infrastructure based on ASTs and AST rewriting.
There should also be better support for navigating between a node in an AST
(or an AST binding) and the corresponding element in the Java model (which
would benefit views that present type hierarchies). [JDT Core, JDT UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71129">71129</a>)
<em><img src="ok.gif" width="12" height="12"> Work completed</em> </p>
<p><strong>Expose Java editor functionality.</strong> Make functionality currently
found in the Java editor available to other plug-ins by pushing it down into
Platform Text. The commited portion includes hyperlink style navigation and
configurable spell checking engine. [JDT Text; Platform Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80157">80157</a>)
[Theme: Design for Extensibility] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
</blockquote>
<h4>Proposed Items (Eclipse JDT project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse JDT project)</h4>
<blockquote>
<p><strong>Expose Java editor functionality.</strong> Make functionality currently
found in the Java editor available to other plug-ins by pushing it down into
Platform Text. The deferred portion includes annotation navigation, spell
checking, and quick fix infrastructure. [JDT Text; Platform Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80157">80157</a>)
[Theme: Design for Extensibility]</p>
<p><b>Improve program manipulation infrastructure.</b> AST creation in the presence
of syntax errors should be improved to include partial bindings. The goal
is to support statement level recovery in the AST parser. The performance
of AST creation should be improved by using a special parser and eliminating
one internal layer of ASTs. [JDT Core, JDT UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71129">71129</a>)
</p>
<p><strong>Library projects.</strong> For plug-in development, PDE distinguishes
between the plug-in projects you are working on (source plug-in projects)
and plug-in projects you are working with but not actually changing (binary
plug-in projects). Making this distinction afforts the user the benefits of
having full source for everything in their workspace where it's easily browsed
and searched, while permitting economies because the latter kind of projects
do not actually have to be (re)compiled. This work item is to support a similar
notion of library project for Java development in general. The user would
be able to flag a Java project as a library project; JDT would know how present
library projects appropriately at the UI, and how to deal with them more efficiently
using generated binaries. [JDT Core, JDT UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80162">80162</a>)
[Theme: Design for Extensibility]</p>
<p><strong>Search enhancements.</strong> Provide additional search queries to
enable more precise searching; e.g., find where is a exception thrown/caught,
match against method parameters in reference searches. [JDT Core, JDT UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71130">71130</a>)</p>
</blockquote>
<p>(End of items for Eclipse JDT project.)
<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&nbsp;tools for developing plug-ins for the
Eclipse Platform. The following work items reflect new features of PDE, or areas
where existing features will be significantly reworked.
<h4>Committed Items (Eclipse PDE project)</h4>
<blockquote>
<p><b>RCP support.</b> PDE currently supports developing Eclipse plug-ins, but
is not expressly geared for the specific needs of clients developing applications
based on the RCP. PDE should facilitate developing and deploying RCP-based
applications. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71131">71131</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
<p><strong>OSGi bundle manifest tooling.</strong> In OSGi, bundles are defined
using standard JAR manifest.mf files. PDE 3.0 contains a rudimentary manifest
editor. This support will be expanded in 3.1 to include support for import/export
package, increased dependency validation, and tools for &quot;bundlizing&quot;
third-party non-Eclipse JARs. [PDE] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80165">80165</a>)
[Theme: Rich Client Platform] <em><img src="ok.gif" width="12" height="12">
Work completed</em></p>
</blockquote>
<h4>Proposed Items (Eclipse PDE project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse PDE project)</h4>
<blockquote>
<p><strong>Improved target support.</strong> PDE manages a model of the target
Eclipse for which you are developing. These targets may be complex and diverse
and switching targets or launch configurations can be expensive. PDE will
be extended to support named targets, and automatically track changes to the
workspace affecting targets. [PDE] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80163">80163</a>)
[Theme: Rich Client Platform]</p>
</blockquote>
<p>(End of items for Eclipse PDE project.)</p>
</body>
</html>