<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="Author" content="Eclipse Platform PMC">
<title>Eclipse Platform Project Draft 3.2 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>

<body>

<h1>Eclipse Platform Project<br>
  DRAFT 3.2 Plan</h1>
<p>Last revised 13:21 EDT Aug. 5, 2005 (<img border="0" src="new.gif" alt="(new)" width="12" height="12"> 
  marks interesting changes since the <a href="eclipse_project_plan_3_2_20050214.html">initial 
  draft of Feb. 14, 2005</a>)</p>
<p>  <i>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to the </i><a href="mailto:eclipse-dev@eclipse.org">eclipse-dev@eclipse.org</a> 
  <i>developer mailing list.</i></p>
<p>This document lays out the feature and API set for the next feature release 
  of the Eclipse Platform after 3.1, designated release 3.2. 
<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 Platform 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 Platform top-level project. Each plan item covers a feature or API 
  that is to be added to the Eclipse Platform, or some aspect of the Eclipse Platform 
  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 Platform Project, available as versions 
    tagged &quot;R3_2&quot; in the Eclipse Platform Project <a href="http://dev.eclipse.org/viewcvs/">CVS 
    repository</a>.</li>
  <li>Eclipse Platform 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 Platform 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. 12, 2005 - Milestone 1 (3.2 M1) - stable build</li>
  <li> Friday Sep. 23, 2005 - Milestone 2 (3.2 M2) - stable build</li>
  <li> Friday Nov. 4, 2005 - Milestone 3 (3.2 M3) - stable build</li>
  <li> Friday Dec. 16, 2005 - Milestone 4 (3.2 M4) - stable build</li>
</ul>
<p>Additional 2006 milestones will be added later. Our target is to complete 3.2 
  in 2Q2006. 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 Platform 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 Platform itself. The 3.2 release of the Eclipse Platform 
  Project is written and compiled against version 1.5 of the Java Platform APIs 
  (i.e., Java SE 5) , and targeted to run on version 1.5 of the Java Runtime Environment, 
  Standard Edition. Portions of the the Eclipse Platform (including the SWT, 
  OSGi and JDT core plug-ins) are targeted to a wider class of operating environments,
  requiring their source code to only reference facilities available in earlier Java
  versions or smaller Java ME profiles [details TBD].</p>
<p>There are many different implementations of the Java Platform running atop 
  a variety of operating systems. We focus Eclipse Platform testing on a handful 
  of popular <span class="header">combinations of operating system and Java Platform; 
  these are our <em>reference platforms</em>. Eclipse undoubtedly runs fine in 
  many operating environments beyond the reference platforms we test. However, 
  since we do not systematically test them we cannot vouch for them. Problems 
  encountered when running Eclipse on a non-reference platform that cannot be recreated 
  on any reference platform will be given lower priority than problems with running 
  Eclipse on a reference platform.</span></p>
<p>Eclipse Platform SDK 3.2 is tested and validated on the following reference 
  platforms (this list is updated over the course of the release cycle):</p>
<table width="821" border="1" summary="Eclipse Reference Platforms">
  <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" alt="(new)" width="12" height="12"> Sun 
      Java 2 Standard Edition 5.0 Update 4 for Microsoft Windows</td>
  </tr>
  <tr>
    <td width="205">Microsoft Windows XP</td>
    <td width="76">Intel x86</td>
    <td width="59">Win32</td>
    <td width="453"> <p> <img border="0" src="new.gif" alt="(new)" width="12" height="12"> 
        IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0</p>
    </td>
  </tr>
  <tr>
    <td width="205" height="22"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> 
      Red Hat Enterprise Linux WS 4</td>
    <td width="76">Intel x86</td>
    <td width="59">GTK</td>
    <td width="453"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> Sun 
      Java 2 Standard Edition 5.0 Update 4 for Linux x86</td>
  </tr>
  <tr>
    <td width="205"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> Red 
      Hat Enterprise Linux WS 4</td>
    <td width="76">Intel x86</td>
    <td width="59">GTK</td>
    <td width="453"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> IBM 
      32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0</td>
  </tr>
  <tr>
    <td width="205">SLES 9</td>
    <td width="76">Intel x86</td>
    <td width="59">GTK</td>
    <td width="453"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> Sun 
      Java 2 Standard Edition 5.0 Update 4 for Linux x86</td>
  </tr>
  <tr>
    <td width="205">SLES 9</td>
    <td width="76">Intel x86</td>
    <td width="59">GTK</td>
    <td width="453"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> IBM 
      32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0</td>
  </tr>
  <tr>
    <td width="205"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> Sun 
      Solaris 10</td>
    <td width="76">SPARC</td>
    <td width="59">Motif</td>
    <td width="453"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> Sun 
      Java 2 Standard Edition 5.0 Update 2 for Solaris SPARC</td>
  </tr>
  <tr>
    <td width="205">HP HP-UX 11i</td>
    <td width="76">hp9000<br>
      PA-RISC</td>
    <td width="59">Motif</td>
    <td width="453"><p><img border="0" src="new.gif" alt="(new)" width="12" height="12"> HP-UX 
        JDK for the Java 2 Platform Standard Edition for 5.0 01</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><img border="0" src="new.gif" alt="(new)" width="12" height="12"> 
        IBM 32-bit SDK for AIX, Java 2 Technology Edition 5.0</p>
    </td>
  </tr>
  <tr>
    <td width="205"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> Apple 
      Mac OS X 10.4</td>
    <td width="76">PowerPC</td>
    <td width="59">Carbon</td>
    <td width="453"><img border="0" src="new.gif" alt="(new)" width="12" height="12"> Java 
      2 Platform Standard Edition (J2SE) 5.0 Release 1 for Tiger</td>
  </tr>
</table>
<p>Although untested, the Eclipse Platform should work fine on other OSes that 
  support the same window system. For Win32: Windows 98, ME, NT, 2000, and Server 
  2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other 
  Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries 
  (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on other 
  Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.</p>
<p>An early access version of the Eclipse Platform is also available for 64-bit 
  Linux GTK. Testing has been limited to early access 64-bit J2SEs running on 
  x86-64 processors.</p>
<p>SWT is also supported on the QNX Neutrino operating system, x86 processor, 
  Photon window system, and IBM J9 VM version 2.0. Eclipse 3.2 on Windows or Linux 
  can be used to cross-develop QNX applications. (Eclipse 3.2 is unavailable on QNX 
  because there is currently no 1.5 J2SE for QNX.)</p>
<h4>Internationalization</h4>
<p>The Eclipse 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 Platform SDK on all of the above 
  operating environments; DBCS locales are supported by the Eclipse Platform SDK 
  on the Windows, GTK, and Motif window systems; BIDI locales are supported by 
  the Eclipse Platform SDK only on Windows operating environments. 
<p>The Eclipse Platform SDK supports GB 18030 (level 1), the Chinese code page 
  standard, on Windows XP and 2000, and Linux/GTK. 
<p>German and Japanese locales are tested.</p>
<h4>BIDI support</h4>
<p>SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering 
  and displaying BIDI text. Within these limitations, the Eclipse Platform
  SDK tools are BIDI enabled.</p>
<h2><a name="Compatibility"></a>Compatibility with Previous Releases</h2>
<h3>Compatibility of Release 3.2 with 3.1</h3>
<p>Eclipse 3.2 will be compatible with Eclipse 3.1 (and, hence, with 3.0).</p>
<p><b>API Contract Compatibility:</b> Eclipse SDK 3.2 will be upwards contract-compatible 
  with Eclipse SDK 3.1 except in those areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_2_porting_guide.html" target="_top"><em>Eclipse 
  3.2 Plug-in Migration Guide</em></a>. Programs that use affected APIs and extension 
  points will need to be ported to Eclipse SDK 3.2 APIs. Downward contract compatibility 
  is not supported. There is no guarantee that compliance with Eclipse SDK 3.2 
  APIs would ensure compliance with Eclipse SDK 3.1 APIs. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving 
  Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain 
  contract compatibility.</p>
<p><b>Binary (plug-in) Compatibility:</b> Eclipse SDK 3.2 will be upwards binary-compatible 
  with Eclipse SDK 3.1 except in those areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_2_porting_guide.html" target="_top"><em>Eclipse 
  3.2 Plug-in Migration Guide</em></a>. Downward plug-in compatibility is not 
  supported. Plug-ins for Eclipse SDK 3.2 will not be usable in Eclipse SDK 3.1. 
  Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving 
  Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain 
  binary compatibility. 
<p><b>Source Compatibility:</b> Eclipse SDK 3.2 will be upwards source-compatible 
  with Eclipse SDK 3.1 except in the areas noted in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_2_porting_guide.html" target="_top"><em>Eclipse 
  3.2 Plug-in Migration Guide</em></a>. This means that source files written to 
  use Eclipse SDK 3.1 APIs might successfully compile and run against Eclipse 
  SDK 3.2 APIs, although this is not guaranteed. Downward source compatibility 
  is not supported. If source files use new Eclipse SDK APIs, they will not be 
  usable with an earlier version of the Eclipse SDK. 
<p><b>Workspace Compatibility:</b> Eclipse SDK 3.2 will be upwards workspace-compatible 
  with Eclipse SDK 3.1 unless noted. This means that workspaces and projects created 
  with Eclipse SDK 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.2 and 
  upgraded to a 3.2 workspace. This includes both hidden metadata, which is localized 
  to a particular workspace, as well as metadata files found within a workspace 
  project (e.g., the .project file), which may propagate between workspaces via 
  file copying or team repositories. Individual plug-ins developed for Eclipse 
  SDK 3.2 should provide similar upwards compatibility for their hidden and visible 
  workspace metadata created by earlier versions; 3.2 plug-in developers are responsible 
  for ensuring that their plug-ins recognize 3.1, 3.0, 2.1, and 2.0 metadata and 
  process it appropriately. User interface session state may be discarded when 
  a workspace is upgraded. Downward workspace compatibility is not supported. 
  A workspace created (or opened) by a product based on Eclipse 3.2 will be unusable 
  with a product based an earlier version of Eclipse. Visible metadata files created 
  (or overwritten) by Eclipse 3.2 will generally be unusable with earlier versions 
  of Eclipse. 
<p><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 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>The changes under consideration for the next release of Eclipse Platform, JDT, 
  and PDE will address major themes identified by the Eclipse Requirements Council 
  (Themes and Priorities dated Dec. 15, 2004 - <a href="http://www.eclipse.org/org/councils/20041215EclipseTPFinalDraft.pdf">pdf)</a>. 
  The following are especially germane to this top level project:</p>
<ul>
  <li><strong>Scaling Up</strong> - This refers to the need for Eclipse to deal 
    with development and deployment on a larger and more complex scale. Increasing 
    complexities arise from large development teams distributed in different locations, 
    large source code bases and fragile build environments that have been developed 
    incrementally over time, the dynamic nature of new source code bases and their 
    interaction with configuration management, and build environments involving 
    many different tools and build rules.</li>
  <li><strong>Enterprise Ready</strong> - Eclipse should be improved to allow 
    it to be better used by large development organizations.</li>
  <li><strong>Design for Extensibility: Be a Better Platform</strong> - Within 
    the Eclipse community, many development projects are defining new development 
    platforms on top of the Eclipse 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><strong>Simple to Use</strong> - 
	The Eclipse components need to not only provide the features that advanced users demand,
	but also be something that most users find simple to use.</li>
  <li><strong>Rich Client Platform</strong> - 
	The Eclipse RCP is a Java-based application framework for the desktop. Building on the
	Eclipse runtime and the modular plug-in story, it is possible to build applications ranging from
	command line tools to feature-rich applications that take full advantage of SWT's native
	platform integration and the many other reusable components.</li>
  <li><strong>Appealing to the Broader Community</strong> - 
	This theme includes work that grows deeper roots into the various OS-specific communities,
	spreads Eclipse to additional operating environments, virtual machines, application
	development and deployment lifecycles, vertical market-specific frameworks and builds
	bridges to other open source communities.</li>
</ul>
<p>Each of the 3 projects under the Eclipse Platform top-level project is covered 
  in its own section: </p>
<ul>
  <li><a href="#Platform">Eclipse Platform project</a></li>
  <li><a href="#JDT">Java development tools (JDT) project</a></li>
  <li><a href="#PDE">Plug-in development environment (PDE) project</a></li>
</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><i>None at this time.</i></p>
  </blockquote>
<h4>Proposed Items (Eclipse Platform project)</h4>
<blockquote> 
  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> revived 
    plan item) <strong>Support logical model integration.</strong> The Eclipse 
    Platform supports a strong physical view of projects containing resources 
    (files and folders) in the workspace. However, there are many situations where 
    plug-in developers would prefer to work with a logical model that is appropriate 
    to their domain. Eclipse should ease the task for plug-in developers who want 
    to make logical model-aware plug-ins. To do this, Eclipse should provide more 
    flexible mechanisms for contributing actions on models that do not have a 
    one-to-one mapping to files on the users hard disk. This would, for example, 
    allow a team provider's repository operations to be made available on logical 
    artifacts. In addition, existing views like the navigator and problems view 
    should be generalized to handle logical artifacts and, in general, there should 
    be better control over what is displayed in views and editors based on the 
    logical models that the end user is working on. [Platform Core, UI, Team] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">37723</a>) 
    [Theme: Design for Extensibility]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new plan 
    item) <strong>Provide more flexible workspaces.</strong> Currently in Eclipse 
    there is a direct connection between IResources and files and directories 
    on the local file system. Eclipse should loosen this connection, by abstracting 
    out its dependency on java.io.File, and allowing for alternative implementations. 
    This would enable, for example, uses where the workspace is located on a remote 
    server, or accessed via a non-file-based API, or has a non-trivial mapping 
    between the resources and the physical layout of the files. [Platform Resources, 
    Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106176">106176</a>) 
    [Theme: Design for Extensibility, Enterprise Ready]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve and extend the SWT widget set.</strong> Modern UI design is 
    a constantly moving target. SWT should provide the tools needed to implement 
    first class user interfaces. For example: sort indicators in SWT tables; improved 
    coolbar behavior/appearance; and new controls such as collapsible groups. 
    [SWT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106182">106182</a>) [Theme: Design for 
    Extensibility, Appealing to the Broader Community]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Address new window system capabilities.</strong> SWT's basis in native 
    widgets is one of Eclipse's major strengths. For this to remain true, SWT 
    must continue to grow to encompass new mainstream desktop platforms and new 
    capabilities added to existing platforms. SWT should support Windows Vista, 
    and handle the GB18030-2 Chinese character set where it is supported natively. 
    [SWT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106184">106184</a>) [Theme: Appealing 
    to the Broader Community]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Update Enhancements.</strong> As the number and range of Eclipse 
    plug-ins continues to grow, it becomes increasingly important to have a powerful 
    update/install story. For instance, if more information about an Eclipse install 
    was available earlier, it would be possible to pre-validate that it would 
    be a compatible location to install particular new features and plug-ins. 
    This information could also be used to deal with conflicting contributions. 
    Update should also be improved to reduce the volume of data that is transferred 
    for a given update, and PDE should provide better tools for creating and deploying 
    updates. [Update, Platform Runtime, PDE] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106185">106185</a>) [Theme: Enterprise Ready]</p>

<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Increase flexibility when building RCP applications.</strong>
The Eclipse text editor should better support RCP applications, by making
features like the following available to them: annotation presentation and
navigation, user assigned colors and fonts, spell checking, folding,
quick diff, templates, and file buffers. The Eclipse workbench layout should
be further opened up to allow RCP applications to have more control over its
presentation. More generally, the dependencies between low level
components, such as the extension registry and platform runtime, should be
reduced to allow them to be more easily reused.
[Platform Text, UI, Runtime]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106187">106187</a>)
[Theme: Rich Client Platform]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Give OSGi a first class presence on eclipse.org.</strong> Eclipse is 
    based on an efficient, highly scalable OSGi implementation, which has always 
    been usable as a standalone component. OSGi should have a first class presence 
    on eclipse.org, including making it easy for developers to reuse the Eclipse 
    OSGi implementation in their own applications. To support this, a separate 
    OSGi download should be provided, as is done for SWT. [Platform Core] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106188">106188</a>) [Theme: Appealing to the Broader Community, Rich Client 
    Platform]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Provide a more customizable UI.</strong> Products often need direct 
    control over the presence and arrangement of UI elements. Similarly, end users 
    expect to be able to customize the UI to better match their workflow. Eclipse 
    should enable both products and end users to have more control over the user 
    interface. For example, better control over the presence and ordering of menu 
    and toolbar items should be provided. Similarly, the workbench layout should 
    be made more flexible and configurable. [Platform UI] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106189">106189</a>) [Theme: Simple to Use]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> revived) 
    <strong>Capabilities/Perspectives/Components.</strong> The UI component has 
    several frameworks for customizing the presentation, filtering the set of 
    available options and supporting task-based UIs tailored to the user's role. 
    This support should be simplified and made more flexible. [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" alt="(new)" width="12" height="12"> new) <strong>Provide more support for large scale workspaces.</strong> In some 
    situations, users have workspaces containing hundreds of projects and hundreds 
    of thousands of files. Scoped builds and working sets have become important 
    tools for these users, and the performance optimizations done in Eclipse 3.1 
    have proven helpful. Eclipse should have even more support for dealing with 
    very large workspaces, including improved searching, filtering, working sets, 
    and bookmarks. This goes hand-in-hand with ongoing work to discover and address 
    performance issues. [Platform UI, Resources] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106192">106192</a>) [Theme: Scaling Up, Enterprise Ready]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve 
    serviceability.</strong> When an end user encounters a problem with Eclipse, 
    it is important for support teams to be able to diagnose the root cause of 
    the failure, and identify the failing plug-in. Eclipse should have enhanced 
    error reporting tools that make it easy for end users to report problems. 
    Tools should be available at all times, so that knowledgeable users could 
    diagnose unexpected behavior such as slowdowns or exceptional memory use. 
    [Platform Runtime, UI, SWT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106193">106193</a>) 
    [Theme: Simple to Use, Enterprise Ready]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> revived) 
    <strong>Embedding editors and views.</strong> Various problems are encountered 
    when trying to embed editors or views within other workbench parts. For example, 
    the current compare infrastructure requires creating a separate text editor 
    for viewing changes between files. This is due to a limitation in the workbench 
    that prevents editors from being embedded inside views or other controls. 
    As a consequence, the compare editor's nested editors don't support the full 
    set of features provided by the corresponding real content-type-specific editor. 
    This represents a major usability problem: the user must switch to the real 
    editor to make changes and then return to the compare view to review the changes. 
    Eclipse should be more flexible in the ways various editors can be used and 
    reused. The UI component model should be improved to support nesting of workbench 
    parts, and reduce the coupling of parts to particular locations in the workbench, 
    allowing for more flexible UI configurations. [Platform UI, Compare, Platform 
    Text] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71125">71125</a>) 
    [Theme: Design for Extensibility] 
  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Enhance the text editor.</strong> The Eclipse Text component provides 
    a powerful editing framework that is useful in many contexts, but some of 
    its capabilities are currently only available in the Java editor. The Java 
    editor should be opened up to allow more general access to the reconciling, 
    code assist, and template proposal mechanisms. Other enhancements to the look 
    and feel of the editor should also be considered in areas such as the Find/Replace 
    dialog, showing change history and comments in the editor, and annotation 
    roll-overs. [Platform Text] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106194">106194</a>)
    [Theme: Design for Extensibility]
    
<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve cheat sheet support.</strong>
The Eclipse cheat sheet infrastructure was implemented 3.0,
but is still not widely used. For cheat sheets to be become
more widely adopted, the base support should be
enhanced in several ways, including: allowing cheat sheets to be
authored by non-developers (i.e. creating steps and registering a cheat
sheet with no programming); defining and using new automation APIs
to allow UI parts like dialogs and wizards to be opened and filled in;
and reworking the implementation to support a single content delivery
mechanism.
[Help, UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106196">106196</a>)
[Theme: Simple to Use, Design for Extensibility]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Provide pervasive user-assistance search capabilities.</strong> An 
    important element of the user-assistance support in Eclipse is the federated 
    help search support that was added in R3.1. This support should be expanded 
    to pull in more useful results from various sources. It should also be made 
    more extensible to assist other information contributors, and made more pervasive 
    in the UI. [Help, UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106198">106198</a>) 
    [Theme: Simple to Use]</p>

<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve task assistance in text fields.</strong>
Eclipse has numerous wizards and dialogs that contain text fields
where there are constraints on the values that can be entered, and often
task assistance can be provided, for example, in the form of potential values.
Eclipse should provide an enhanced text field that has indicators for
required fields, and content assist.
[Help, UI]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106199">106199</a>)
[Theme: Simple to Use]</p>

<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Provide a single user-assistance content delivery mechanism.</strong>
In Eclipse 3.1, three different user-assistance vehicles are
used to help users in various contexts:
the initial user experience shows the 'Welcome' content;
cheat sheets assist during long tasks; Help shows the traditional help
topics. These vehicles use similar concepts but have separate/duplicate
code bases. They should be reworked so that a single content delivery
mechanism is used in various contexts, allowing content producers to
benefit from a single way of contributing content, making all the
content searchable, and making it presentable in various contexts. This
should also take into account whether content is local or remote.
[Help]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106200">106200</a>)
[Theme: Design for Extensibility]</p>

<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Separate information content from presentation.</strong>
In previous releases, Eclipse Help manipulated content as a reference.
Although the representation is simple and reliable, it is difficult to
tailor the content for multiple presentations, or to provide incremental
content contributions, content reuse, content filtering etc. 
The representation for help content should be improved.
Also, branding information should be separated from the rest of the content
to simplify aggregating multiple contributions into larger units.
[Help, UI, Core, Install/Update]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106201">106201</a>)
[Theme: Design for Extensibility]</p>

<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve UI Forms.</strong>
UI Forms are increasingly being used in the Eclipse user interface.
The UI Form support should be improved to allow for more pervasive use
in 3.2. Critical widget functionality should be moved to SWT
to ensure quality and native look and feel. The remaining UI Forms code
(minus FormEditor) should be pushed down into JFace so that it is available
in the Eclipse workbench.
[SWT, UI, Help]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106203">106203</a>)
[Theme: Simple to Use, Design for Extensibility]</p>
  
  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Enhance the debug platform.</strong> The debug support in Eclipse 
    is increasingly being used in areas that require more flexible mechanisms 
    than those required by simple Java programs. Potential work areas include: 
    the integration of flow control, async/cancellation into debug APIs; update 
    policies in debug views (i.e. ensure view updates before proceeding vs. let 
    debugger go as fast as it can and let the views catch up); a flexible debug 
    model element hierarchy to account for different architectures such as multi-core 
    processors, thousands of threads, etc; and introduction of table trees in 
    standard debug views for better/flexible presentation. [Debug] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106205">106205</a>) 
    [Theme: Design for Extensibility, Enterprise Ready]</p>

  </blockquote>
<h4>Deferred Items (Eclipse Platform project)</h4>
<blockquote> 
  <p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse Platform project.)</p>
<h2><a name="JDT">Java development tools (JDT) project</a></h2>
<p><a href="http://www.eclipse.org/jdt/index.html">Java development tools</a> (JDT)
implements a Java IDE based on the Eclipse Platform. The following work items
reflect new features of JDT, or areas where existing features will be
significantly reworked.</p>
<h4>Committed Items (Eclipse JDT project,)</h4>
<blockquote> 
  <p><i>None at this time.</i></p>
  </blockquote>
<h4>Proposed Items (Eclipse JDT project)</h4>
<blockquote> 

<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Add support for Java SE 6 features.</strong>
Java SE 6 (aka "Mustang") will likely contain improvements to javadoc tags
(like @category), classfile specification updates, pluggable annotation
processing APIs, and new compiler APIs, all of which will require specific
support.
[JDT Core, JDT UI, JDT Text, JDT Debug]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106206">106206</a>) 
[Theme: Appealing to the Broader Community]</p>
    
  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve refactoring.</strong> Refactoring currently relies on a closed 
    world assumption. This means that all of the code to be refactored must be 
    available in the workspace when the refactoring is triggered. However for 
    large distributed teams, the closed world approach isn't really feasible. 
    The same is true for clients which use binary versions of libraries where 
    API changes from one version to another. In 3.2 the closed world assumptions 
    will be relaxed in such a way that a refactoring executed in workspace A can 
    be "reapplied" on workspace B to refactor any remaining references to the 
    refactored element. Furthermore, existing refactorings will be improved to 
    preserve API compatibility where possible (for example when renaming a method, 
    a deprecated stub with the old signature will be generated that forwards to 
    the new method). [JDT Core/UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106207">106207</a>) 
    [Theme: Scaling Up].</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> revived) 
    <strong>Implement library projects.</strong> For plug-in development, PDE 
    distinguishes between the plug-in projects you are working on (source plug-in 
    projects) and plug-in projects you are working with but not actually changing 
    (binary plug-in projects). Making this distinction affords the user the benefits 
    of having full source for everything in their workspace where it's easily 
    browsed and searched, while permitting economies because the latter kind of 
    projects do not actually have to be (re)compiled. This work item is to support 
    a similar notion of library project for Java development in general. The user 
    should be able to flag a Java project as a library project; JDT would then 
    know how to present library projects appropriately at the UI, and how to deal 
    with them more efficiently using generated binaries. [JDT Core, JDT UI, PDE] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=80162">80162</a>) 
    [Theme: Design for Extensibility]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve 
    NLS tooling.</strong> The Eclipse NLS tooling should better support the the 
    new Eclipse string externalization pattern added in 3.1, along with ways to 
    help developers with unused keys and unused property file entries. [JDT Text] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106210">106210</a>) 
    [Theme: Simple to use, Scaling up]</p>
    
  </blockquote>
<h4>Deferred Items (Eclipse JDT project)</h4>
<blockquote>
  <p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse JDT project.)
<h2><a name="PDE">Plug-in development environment (PDE) project</a></h2>
The <a href="http://www.eclipse.org/pde/index.html">plug-in development
environment</a> (PDE) consists of tools for developing plug-ins for the
Eclipse Platform. The following work items reflect new features of PDE, or areas
where existing features will be significantly reworked.
<h4>Committed Items (Eclipse PDE project)</h4>
<blockquote>
  <p><i>None at this time.</i></p>
</blockquote>
<h4>Proposed Items (Eclipse PDE project)</h4>
<blockquote> 

<p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve target support.</strong>
PDE manages a model of the target Eclipse for which you are
developing. Targets may be complex and diverse, and
switching targets or launch configurations can be expensive.
PDE should be extended to support named targets and automatically
track changes to the workspace.
[PDE, Core]
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106211">106211</a>)
[Theme: Simple to Use, Enterprise Ready]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>New source lookup for debugging Eclipse applications.</strong> The 
    default source lookup mechanism for debugging Java applications has scalability 
    issues since the debugger may needing to scan a list of hundreds of plug-in 
    projects each time it look up a source file. PDE should provide its own source 
    path computer to which the debugger can delegate the task of locating source 
    files. In addition to faster lookups, the PDE-based approach will be better 
    positioned to handle duplicate source files on the same source path. It would 
    also allow the user to easily debug plug-ins against different targets without 
    having to change the Target Platform in the preferences. [PDE, Debug, Core] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106212">106212</a>)
    [Theme: Scaling Up]</p>
    
  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>API-aware tools.</strong> Given the importance that the Eclipse community 
    places on stable, robust APIs, having good support for their implementation 
    is critical. The support within Eclipse for describing APIs should be improved, 
    along with better tools from assisting developers to stick to APIs provided 
    by other plug-ins. [PDE, JDT] 
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106213">106213</a>)
    [Theme: Enterprise Ready]</p>

  <p>(<img border="0" src="new.gif" alt="(new)" width="12" height="12"> new) <strong>Improve PDE build.</strong> PDE Build is fundamental to how the Eclipse 
    Platform releases are produced. It is also increasingly being used by other 
    Eclipse projects and in the wider community. Potential improvements to PDE 
    build include parallel cross-building, incremental building of plug-ins, increased 
    integration with the workspace model, and support for additional repository 
    providers. [PDE]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=106214">106214</a>)
    106214[Theme: Enterprise Ready]</p>

  </blockquote>
<h4>Deferred Items (Eclipse PDE project)</h4>
<blockquote>
  <p><i>None at this time.</i></p>
</blockquote>
<h4>(End of items for Eclipse PDE project.)</h4>
</body>

</html>