Google Git
Sign in
eclipse / www.eclipse.org / eclipse / 57052bc9d06420299c19552ecdec753605462ffe / . / development / eclipse_project_plan_3_1_20041214.html
blob: c0ca10a613a08c2d6232090c5e18408314d4de34 [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 Draft 3.1 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>
<h1>Eclipse Project<br>
DRAFT 3.1 Plan</h1>
<p>Last revised 18:00 EST December 14, 2004 (<img border="0" src="new.gif" width="12" height="12">
marks interesting changes since the <a href="eclipse_project_plan_3_1_20040729.html">initial
draft of July 29, 2004</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>
</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 - <img border="0" src="new.gif" width="12" height="12">
API complete - API freeze</li>
<li><img border="0" src="new.gif" width="12" height="12"> Friday May 13, 2005
- Milestone 7 (3.1 M7) - stable build - feature complete - development freeze
- lock down and testing begins</li>
</ul>
<p>The 3.1 release is targeted for late June 2005. 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"><img border="0" src="new.gif" width="12" height="12"> Sun
Java 2 Standard Edition, version 1.4.2_06 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><img border="0" src="new.gif" width="12" height="12">
IBM 32-bit SDK for Windows, Java 2 Technology Edition, Version 1.4.2_01</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 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"><img border="0" src="new.gif" width="12" height="12"> Sun
Java 2 Standard Edition, 1.4.2_06 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"><img border="0" src="new.gif" width="12" height="12"> IBM
32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition, Version
1.4.2_01</td>
</tr>
<tr>
<td width="205"><img border="0" src="new.gif" width="12" height="12"> SLES
9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453"><img border="0" src="new.gif" width="12" height="12"> Sun
Java 2 Standard Edition, version 1.4.2_06 for Linux x86</td>
</tr>
<tr>
<td width="205"><img border="0" src="new.gif" width="12" height="12"> SLES
9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453"><img border="0" src="new.gif" width="12" height="12"> IBM
32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition, Version
1.4.2_01</td>
</tr>
<tr>
<td width="205">Sun Solaris 8</td>
<td width="76">SPARC</td>
<td width="59">Motif</td>
<td width="453"><img border="0" src="new.gif" width="12" height="12"> Sun
Java 2 SDK, Standard Edition, 1.4.2_06 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"><span class="header"><img border="0" src="new.gif" width="12" height="12">
HP-UX SDK for the Java 2 platform, version 1.4.2.06 for hp9000 PA-RISC</span></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><img border="0" src="new.gif" width="12" height="12">
IBM 32-bit SDK for AIX, Java 2 Technology Edition, Version 1.4.2</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 AMD64
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, the new Chinese code page standard, on
Windows XP and 2000, and Linux.
<p>German and Japanese locales are tested.</p>
<h4>BIDI support</h4>
<p>SWT fully supports BIDI on Windows (only). On Linux GTK, SWT supports entering
and displaying BIDI text. <img border="0" src="new.gif" width="12" height="12">
The widget orientation of JFace windows defaults appropriately in BIDI locales
on Windows (only).</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</h2>
<p>The changes under consideration for the next release of Eclipse Platform, JDT,
and PDE address a few major themes:</p>
<ul>
<li><b>Built to last </b>- Eclipse has always been a platform for delivering
integrated software tools. With a large and growing base of both free and
commercial offerings based on Eclipse, it's critical for continued success
to maintain API stability and ensure that the platform scales well. This
theme includes work to measure and improve the performance of key operations
under various loads (number of installed plug-ins, number of resources in
the workspace, etc.). This theme also includes consolidation activities
where groundwork was laid in 3.0 but needs to be completed and brought into
full use.</li>
<li><b>Simple to use</b> - The Eclipse platform needs to not only provide the
features that advanced users demand, but also be something that most users
find simple to use. This theme includes ease-of-use reviews of existing
features, and work that helps make Eclipse-based products simple to use for
users with widely-varying backgrounds and skill sets.</li>
<li><b>Rich client platform </b>- The Eclipse RCP is a Java-based application
framework for the desktop. Building on the Eclipse runtime and the modular
plug-in story, it is possible to build applications ranging from command
line tools to feature-rich applications that take full advantage of SWT's
native platform integration and the many other reusable components that the
Eclipse platform provides. This theme includes work to enhance the RCP, and
to provide PDE support for developing and deploying RCP-based applications.</li>
<li><b>J2SE 5 support</b> - This theme covers work to add full support for
J2SE 5 to JDT.</li>
<li><b>Large-scale development </b>- Large software projects are long-term
collaborations involving large teams of developers playing a variety of
roles. In order to be effective for large projects, software tools and
processes must fit well into this reality. This theme includes laying the
groundwork in the Eclipse Platform that will enable large teams to make
effective use of Eclipse-based products.</li>
<li><b>Broadening the community</b> - This theme includes work that grows
deeper roots into the various OS-specific communities, spreads Eclipse to
additional operating environments, and builds bridges to other open source
communities.</li>
</ul>
<p>Since each theme has a number of items, the committed, proposed, and deferred
plan items are grouped in sections by theme. In addition, there are a few
important Eclipse Platform improvements that do not naturally fit into any of
the above themes; these are listed separately.</p>
Each of the 3 projects under the Eclipse top-level project is covered in its
own section:
<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>(<img border="0" src="new.gif" width="12" height="12"> replacement for <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">37723</a>;
recently committed) <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: Built to last; large-scale development]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> recently committed) <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: Large-scale development]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> recently committed)
<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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> recently committed)
<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: Built to last; simple to use]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Large-scale development]</p>
</blockquote>
<h4>Proposed Items (Eclipse Platform project)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> revised item)<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: Simple to use]</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: Large-scale development]</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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>(<img border="0" src="new.gif" width="12" height="12"> new) <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>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Help search
enhancements.</b> Search will be enhanced in a number of ways. Add the ability
to search the workbench UI to find actions, views, perspectives, etc.; 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: Simple to use; large-scale development]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Simple to use]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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>)
[Theme: Large-scale development]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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, spell checking, user defined,
persistent folding, quick diff, templates, URL detection and handling. [Platform
Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80154">80154</a>)
[Theme: Rich client platform]</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>(<img border="0" src="new.gif" width="12" height="12"> updated item) <b>Add
support for J2SE 5 features. </b>J2SE 5 (also known as JDK 1.5 &quot;Tiger&quot;)
is targeted to ship in the second half of 2004. This release contains <a href="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: J2SE 5 support]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <strong>Improved
compiler checking.</strong> Add support for detecting references to internal
classes, add warnings about missing declarations of serialVersionUID, and
perform null reference analysis. [JDT Core] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80155">80155</a>)
[Theme: Large-scale development]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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>)
[Theme: Large-scale development]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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. This includes hyperlink style navigation, 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: Built to last]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Large-scale development]</p>
</blockquote>
<h4>Proposed Items (Eclipse JDT project)</h4>
<blockquote>
<p>(<img border="0" src="new.gif" width="12" height="12"> updated item) <b>Improve
program manipulation infrastructure.</b> Parts of the Java model are still
implemented in terms of the deprecated JDOM, an early precursor of the AST
facility. JDT should move to an AST-based implementation of the Java model.
All source and refactoring operations should be rewritten to use common program
manipulation infrastructure based on ASTs and AST rewriting. AST creation
in the presence of syntax errors should be improved to include partial bindings.
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. 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>)
[Theme: Built to last]</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> updated item) <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>)
[Theme: Simple to use]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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: Large-scale development]</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.)
<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><i>None at this time.</i></p>
</blockquote>
<h4>Proposed 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]</p>
<p> (<img border="0" src="new.gif" width="12" height="12"> new) <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>
<p>(<img border="0" src="new.gif" width="12" height="12"> new) <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,
declarative services, 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]</p>
</blockquote>
<h4>Deferred Items (Eclipse PDE project)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>(End of items for Eclipse PDE project.)</h4>
</body>
</html>