| <!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.0 Plan</title> |
| <link rel="stylesheet" href="../../default_style.css" type="text/css"> |
| </head> |
| |
| <body> |
| <h1>Eclipse Project<br> |
| 3.0 Plan (Final)</h1> |
| <p>Last revised Wednesday, June 2, 2004 (<img border="0" src="new.gif" width="12" height="12"> |
| marks interesting changes since the <a href="eclipse_project_plan_3_0_20040428.html">previous |
| draft of April 28, 2004</a>)<br> |
| <br> |
| <i> 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 2.1, designated release 3.0 (<a href="why_eclipse_3_0.html">Why |
| Eclipse "3.0"?</a>). |
| <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 subproject</a></li> |
| <li><a href="#JDT">Java development tools (JDT) subproject</a></li> |
| <li><a href="#PDE">Plug-in development environment (PDE) subproject</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. |
| <p>The remainder of the plan consists of plan items for the various Eclipse |
| subprojects. 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, 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. All interesting feature work is accounted for in |
| this plan. |
| <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, deferred, or rejected.</li> |
| <li><b>Deferred</b> plan item - A reasonable proposal that will not make it in |
| to this release for some reason is marked as deferred with a brief note as |
| to why it was deferred. Deferred plan items may resurface as committed plan |
| items at a later point.</li> |
| <li><b>Rejected</b> plan item - Plan items that were proposed but judged |
| unworkable are marked as rejected plan items, with an accompanying summary |
| of why they were dismissed. Keeping track of rejected items avoids repeating |
| the discussion.</li> |
| </ul> |
| <h2><a name="Deliverables"></a>Release deliverables</h2> |
| <p>The release deliverables have the same form as previous releases, namely: |
| <ul> |
| <li>Source code release for Eclipse Project, available as versions tagged |
| "R3_0" in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS |
| repository</a>.</li> |
| <li>Eclipse Project SDK (includes Platform, JDT, and PDE source zips) |
| (downloadable).</li> |
| <li>Eclipse Platform runtime binary distribution (downloadable).</li> |
| <li>JDT runtime binary distribution (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 June 6, 2003 - Milestone 1 (3.0 M1) - stable build reflecting progress</li> |
| <li>Friday July 18, 2003 - Milestone 2 (3.0 M2) - stable build reflecting progress</li> |
| <li>Friday August 29, 2003 - Milestone 3 (3.0 M3) - stable build reflecting |
| progress</li> |
| <li>Friday October 10, 2003 - Milestone 4 (3.0 M4) - stable build reflecting |
| progress</li> |
| <li>Friday November 21, 2003 - Milestone 5 (3.0 M5) - initial API freeze for |
| breaking changes - stable build reflecting progress</li> |
| <li>Friday December 19, 2003 - Milestone 6 (3.0 M6) - API freeze for breaking |
| changes - stable build with focus on reducing the bug backlog and fixing memory |
| leaks</li> |
| <li>Friday February 13, 2004 - Milestone 7 (3.0 M7) - stable build reflecting |
| progress</li> |
| <li>Friday March 26, 2004 - Milestone 8 (3.0 M8) - stable build reflecting progress</li> |
| <li> Friday May 21, 2004 - Milestone 9 (3.0 M9) - stable build - feature complete |
| - development freeze - lock down and testing begins</li> |
| </ul> |
| <p><img border="0" src="new.gif" width="12" height="12"> Lock down and testing |
| then begins with M9, and progress through a series of test-fix passes against |
| candidates releases. Release candidate builds are planned as follows (M9 is |
| release candidate 0):</p> |
| <ul> |
| <li>Friday May 28, 2004 - Release Candidate 1 - (3.0 RC1)</li> |
| <li>Friday June 11, 2004 - Release Candidate 2 - (3.0 RC2)</li> |
| <li>Friday June 18, 2004 - Release Candidate 3 - (3.0 RC3)</li> |
| <li>Friday June 25, 2004 - Release Candidate 4 - (3.0 RC4)</li> |
| </ul> |
| <p> Depending on the circumstances, we may add additional release candidate builds |
| or fine-tune the schedule. The 3.0 release is targeted for the week of June |
| 28, 2004. See the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-project-home/plans/3_0/freeze_plan.html">Eclipse |
| 3.0 Endgame Plan</a> for further details. All release deliverables will be available |
| for download as soon as the release has been tested and validated in the target |
| operating configurations listed below.</p> |
| <h2><a name="TargetOperatingEnvironments"></a>Target Operating Environments</h2> |
| <p>In order to remain current, each Eclipse release targets reasonably current |
| versions of the underlying operating environments.</p> |
| <p>Most of the Eclipse SDK is "pure" 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.0 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.0 is tested and validated on the following reference platforms |
| (this list is updated over the course of the release cycle):</p> |
| <table width="821" border="1"> |
| <tr bgcolor="#CCCCCC"> |
| <th colspan="4"> |
| <div align="center"> |
| <b><font size="+1">Eclipse Reference Platforms</font></b> |
| </div> |
| </th> |
| </tr> |
| <tr> |
| <td width="205"><b>Operating system</b></td> |
| <td width="76"><b>Processor architecture</b></td> |
| <td width="59"><b>Window system</b></td> |
| <td width="453"><b>Java 2 Platform</b></td> |
| </tr> |
| <tr> |
| <td width="205">Microsoft Windows XP</td> |
| <td width="76">Intel x86</td> |
| <td width="59">Win32</td> |
| <td width="453">Sun Java 2 SDK, Standard Edition, version 1.4.2_03 for Microsoft |
| Windows</td> |
| </tr> |
| <tr> |
| <td width="205">Microsoft Windows XP</td> |
| <td width="76">Intel x86</td> |
| <td width="59">Win32</td> |
| <td width="453"> |
| <p>IBM 32-bit SDK for Windows, Java 2 Technology Edition, Version 1.4.1</p> |
| </td> |
| </tr> |
| <tr> |
| <td width="205">Red Hat Enterprise Linux WS 3</td> |
| <td width="76">Intel x86</td> |
| <td width="59">GTK</td> |
| <td width="453">Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86</td> |
| </tr> |
| <tr> |
| <td width="205">Red Hat Enterprise Linux WS 3</td> |
| <td width="76">Intel x86</td> |
| <td width="59">GTK</td> |
| <td width="453">IBM 32-bit SDK for Linux on Intel architecture, Java 2 |
| Technology Edition, Version 1.4.1</td> |
| </tr> |
| <tr> |
| <td width="205"> SuSE Linux 8.2</td> |
| <td width="76">Intel x86</td> |
| <td width="59">GTK</td> |
| <td width="453">Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86</td> |
| </tr> |
| <tr> |
| <td width="205"> SuSE Linux 8.2</td> |
| <td width="76">Intel x86</td> |
| <td width="59">GTK</td> |
| <td width="453">IBM 32-bit SDK for Linux on Intel architecture, Java 2 |
| Technology Edition, Version 1.4.1</td> |
| </tr> |
| <tr> |
| <td width="205"> Sun Solaris 8</td> |
| <td width="76">SPARC</td> |
| <td width="59">Motif</td> |
| <td width="453">Sun Java 2 SDK, Standard Edition, 1.4.2_03 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">HP-UX SDK for the Java 2 platform, version |
| 1.4.2.00 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>IBM 32-bit SDK for AIX, Java 2 Technology Edition, Version 1.4.1</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.1 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 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.0 on Windows or Linux |
| can be used cross develop QNX applications. (Eclipse 3.0 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.</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> |
| <p>Eclipse 3.0 will be compatible with Eclipse 2.0 and 2.1 to the greatest |
| extent possible.</p> |
| <h3>Compatibility of Release 3.0 with 2.0 and 2.1</h3> |
| <p>Eclipse 3.0 will be compatible with Eclipse 2.0 and 2.1 to the greatest extent |
| possible. The nature and scope of some of the key plan items are such that the |
| only feasible solutions would break compatibility. Since breaking changes are |
| a disruption to the Eclipse community, they cannot be taken lightly. We (the |
| Eclipse PMC) will have an open discussion with the community before approving |
| a proposed breaking change for inclusion in 3.0. In other regards, Eclipse 3.0 |
| will be compatible with 2.0 and 2.1. We also aim to minimize the effort required |
| to port an existing plug-in to the 3.0 APIs. We will provide a comprehensive |
| <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html" target="_top"><em>Eclipse |
| 3.0 Porting Guide</em></a> that covers all areas of breaking API changes, and |
| describes how to port existing 2.1 plug-ins to 3.0. Up-to-date drafts of the |
| <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html" target="_top"><em>Eclipse |
| 3.0 Porting Guide</em></a> will be included with milestone builds so that it's |
| possible to climb aboard the 3.0 release wagon at the early stages, or to estimate |
| the amount of effort that will be involved in eventually porting existing plug-ins |
| to 3.0.</p> |
| <p><b>API Contract Compatibility:</b> Eclipse SDK 3.0 will be upwards contract-compatible |
| with Eclipse SDK 2.0 and 2.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_0_porting_guide.html" target="_top"><em>Eclipse |
| 3.0 Porting Guide</em></a>. Programs that use affected APIs and extension points |
| will need to be ported to Eclipse SDK 3.0 APIs. Downward contract compatibility |
| is not supported. There is no guarantee that compliance with Eclipse SDK 3.0 |
| APIs would ensure compliance with Eclipse SDK 2.0 or 2.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.0 will be upwards binary-compatible |
| with Eclipse SDK 2.0 and 2.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_0_porting_guide.html" target="_top"><em>Eclipse |
| 3.0 Porting Guide</em></a>. Eclipse 3.0 will include additional runtime compatibility |
| mechanisms to provide effective binary API compatibility. Downward plug-in compatibility |
| is not supported. Plug-ins for Eclipse SDK 3.0 will not be usable in Eclipse |
| SDK 2.0 or 2.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.0 will be upwards source-compatible |
| with Eclipse SDK 2.0 or 2.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_0_porting_guide.html" target="_top"><em>Eclipse |
| 3.0 Porting Guide</em></a>. This means that source files written to use Eclipse |
| SDK 2.0 or 2.1 APIs might successfully compile and run against Eclipse SDK 3.0 |
| 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.0 will be upwards |
| workspace-compatible with Eclipse SDK 2.0 or 2.1 unless noted. This means that |
| workspaces and projects created with Eclipse SDK 2.0 or 2.1 can be successfully |
| opened by Eclipse SDK 3.0 and upgraded to a 3.0 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.0 should provide similar upwards |
| compatibility for their hidden and visible workspace metadata created by earlier |
| versions; 3.0 plug-in developers are responsible for ensuring that their |
| plug-ins recognize 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.0 will be unusable with a product based an earlier |
| version of Eclipse. Visible metadata files created (or overwritten) by Eclipse |
| 3.0 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 "internal" in its name, are |
| considered implementation details which may vary between operating environment |
| and are subject to change without notice. Client plug-ins that directly depend |
| on anything other than what is specified in the Eclipse SDK API are inherently |
| unsupportable and receive no guarantees about compatibility within a single |
| release much less with 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>Eclipse Project Subprojects</h2> |
| The Eclipse Project consists of 3 subprojects. Each subproject is covered in its |
| own section: |
| <ul> |
| <li><a href="#Platform">Eclipse Platform subproject</a></li> |
| <li><a href="#JDT">Java development tools (JDT) subproject</a></li> |
| <li><a href="#PDE">Plug-in development environment (PDE) subproject</a></li> |
| </ul> |
| <p>For each subproject, the items listed reflect new features of the Eclipse |
| Platform, 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 (<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=JDT&product=PDE&product=Platform&keywords=plan&target_milestone=3.0&target_milestone=3.0+M1&target_milestone=3.0+M2&target_milestone=3.0+M3&target_milestone=3.0+M4&target_milestone=3.0+M5&target_milestone=3.0+M6&target_milestone=3.0+M7&target_milestone=3.0+M8&target_milestone=3.0+M9">query |
| bugzilla for all 3.0 plan items</a>). |
| <h2><a name="Platform">Eclipse Platform subproject</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. Many of the changes under consideration |
| for the next release of the Eclipse Platform address three major themes. Since |
| each theme has a number of items, the committed, proposed, and deferred plan |
| items are grouped in sections by theme:</p> |
| <ul> |
| <li><a href="#ThemeUserExperience">User experience theme</a> - Improving |
| Eclipse from the point of view of the end user.</li> |
| <li><a href="#ThemeResponsiveUI">Responsive UI theme</a> - Making it easier to |
| write Eclipse plug-ins that keep the UI responsive.</li> |
| <li><a href="#ThemeRCP">Rich client platform theme</a> - Generalizing Eclipse |
| into a platform for building non-IDE applications.</li> |
| </ul> |
| <p>In addition, there are important Eclipse Platform improvements that do not |
| naturally fit into any of the above themes.</p> |
| <ul> |
| <li><a href="#OtherPlatform">Other Eclipse Platform items</a></li> |
| </ul> |
| <h3><a name="ThemeUserExperience">Theme: User Experience</a></h3> |
| <p>Improving Eclipse from the point of view of the end user. This includes |
| improving both the "out of the box" experience so that new users are |
| productive faster, and finding better ways to scale up to large numbers of |
| plug-ins without overwhelming the user.</p> |
| <h4>Committed Items (Eclipse Platform subproject, User Experience theme)</h4> |
| <blockquote> |
| <p><b>Improve UI scalability.</b> Despite efforts to ensure UI scalability with |
| a large base of available tools, the Eclipse workbench still intimidates many |
| users with long menus, wide toolbars, and lengthy flat lists of preferences. |
| This problem is acute in large Eclipse-based products. The Platform should |
| provide additional ways for controlling workbench clutter, such as further |
| menu and toolbar customizability, distinguishing between novice and advanced |
| functions, supporting different developer roles, and more specific object |
| contributions for particular file types. [Platform UI, Platform Debug, JDT |
| UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37929">37929</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><b>Improve initial user experience.</b> Users who are new to an Eclipse-based |
| product can find their first experiences with it overwhelming, even daunting. |
| The initial experience would be improved if a product could preconfigure the |
| workbench to show only the subset of function that a new user really needs; |
| welcome pages could be personalized for particular users roles or levels of |
| experience. [Platform UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37664">37664</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><b>Improve UI affordances.</b> There are a number of areas of the UI where |
| Eclipse is not providing enough cues to the user (e.g., no cue for available |
| help, no cue for maximize/restore view, no cue for mandatory/optional fields |
| in wizards). Make a systematic pass though the UI to improve its affordances. |
| [Platform UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37667">37667</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><b>Improve file encoding support.</b> Eclipse 2.1 uses a single global file |
| encoding setting for reading and writing files in the workspace. This is problematic; |
| for example, when Java source files in the workspace use OS default file encoding |
| while XML files in the workspace use UTF-8 file encoding. The Platform should |
| support non-uniform file encodings. [Platform Core, Platform UI, Text, Search, |
| Compare, JDT UI, JDT Core] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37933">37933</a>)<em> |
| <img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Evolve the Eclipse user experience.</b> Eclipse 3.0 should have a new |
| look that makes more effective use of the capabilities of current desktop |
| computers. This includes allowing the user to customize the workbench by creating |
| floating toolbars and views, and supporting tear-off views and dockable toolbars |
| where supported by the underlying window system. [Platform UI, JDT UI, SWT] |
| [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37997">37997</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Improve keyboard bindings. </strong>Several things should be done |
| to improve keyboard bindings. First, custom key bindings currently work only |
| in the main Eclipse window, and not in secondary windows like dialogs, wizards, |
| and floating views (another plan item). For example, custom editor key bindings |
| do not work in a text control in a preference dialog. Eclipse should support |
| custom key bindings in the places where the user reasonably expects. Second, |
| the key customization dialog should be improved. Finally, make a systematic |
| pass through the UI to rationalize the initial set of key bindings. [Platform |
| UI, SWT] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37934">37934</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Improve editor management.</strong> The current mechanism for switching |
| between editors using tabs does not scale to having many open editors. Eclipse |
| should provide a more scalable and stable, yet efficient, UI for switching |
| between editors. [Platform UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37670">37670</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| </blockquote> |
| <blockquote> |
| <p><strong>Improve text editor interaction. </strong>The text editor should |
| support folding of text regions, which can be leveraged by the Java editor |
| to collapse regions, such as an individual method's body or Javadoc comment, |
| or the import declarations of a compilation unit. [Platform Text, JDT UI] |
| [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37671">37671</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Improve text editor presentation.</strong> The text editor should |
| support an optional marginal change bar that can show how the current document |
| differs from another of its states, such as a local history state or a repository |
| version. Also, text editors should support for emphasizing a text region by |
| changing its background color. [Platform Text, JDT UI] [Theme: User Experience] |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37672">37672</a>) <em><img src="ok.gif" width="12" height="12"> |
| Work completed</em></p> |
| <p><strong>Improve text editor typing.</strong> The set of key actions available |
| in the text editor should be enriched with additional common operations like |
| insert line, duplicate line, transpose, and convert to uppercase. The current |
| JDT editor support for templates with variables should be generalized and |
| pushed down so that it is available in all text editors. [Platform Text, JDT |
| UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37674">37674</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Improve global text search/replace.</strong> Global text search should |
| allow regular expressions in search patterns. The replace action should be |
| more visible in the UI, and be easier to use in the case of bulk changes. |
| [Platform Search] [Theme: User Experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37675">37675</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Allow dynamic help content.</strong> Existing help content consists |
| entirely of static HTML pages. Additional flexibility would be provided by |
| allowing help content to include JSPs, possibly with access to the user's |
| Eclipse environment. [Platform Help] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37676">37676</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Simplify update manager UI.</b> User feedback indicates that the update |
| manager UI is too powerful and occasionally confusing to users. It should |
| be simplified in order to provide a clear path for the common tasks, embrace |
| progressively disclosure, separate update search from platform configuration |
| tasks, and make more economical use of screen real estate for properties. |
| [Platform Update] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37678">37678</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Display HTML in a widget.</b> In Eclipse 2.0 and 2.1, the only supported |
| option for rendering HTML in the workbench is to use OLE to link to IE. This |
| support is Windows only; there is no such option in other operating environments. |
| Even on Windows, this only works for IE and not other browsers. There are |
| already several Eclipse components that could benefit from HTML display functionality |
| in a widget: welcome pages; update manager update site overview; hovers that |
| show Javadoc. The Platform should provide a portable way to display HTML in |
| a widget and support it in all operating environments. [Platform UI, SWT] |
| [Themes: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36952">36952</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Allow editors to open files outside workspace.</b> A common request is |
| to be able to use Eclipse to open a file that is not part of the workspace, |
| or perhaps even one on a remote system. The operations and capabilities available |
| on these "outside of the workspace" files would need to be defined. |
| [Platform UI] [Themes: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37935">37935</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Improve workspace synchronization with file system.</b> A file resource |
| in the workspace gets out of sync when the underlying file in the file system |
| is created, deleted, or rewritten outside of Eclipse. File resources usually |
| remains out of sync until the user explicitly hits Refresh. The Eclipse Platform |
| should provide ways to keep the in-memory representation in sync with the |
| file system; for example, by hooking OS file system callbacks where available, |
| and by polling for file system changes in a background thread. [Platform Core, |
| Platform UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36962">36962</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Content-type-based infrastructure.</strong> The choice of editor |
| is currently based on file name patterns. This is not very flexible, and breaks |
| down when fundamentally different types of content are found in files with |
| undistinguished file names or internal formats. For example, many different |
| models with specialized editors get stored in XML format files named *.xml. |
| Eclipse should provide infrastructure support for a notion of content type |
| for files and resources. [Platform Core, Platform UI] [Theme: User experience] |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=60291">60291</a>) <em><img src="ok.gif" width="12" height="12"> |
| Work completed</em></p> |
| <p><strong>Improve support for opening workspaces.</strong> Many users use multiple |
| workspaces as a way to keep their different projects or work items separate. |
| Currently, this requires launching Eclipse multiple times with different command |
| line arguments, which is not particularly convenient for users. Moreover, |
| when the command line argument is not specified, the workspace location defaults |
| to a directory inside where the code for Eclipse is installed. Eclipse should |
| improve how workspaces get opened, use a user-specific default workspace location |
| more suitable for shared multi-user Eclipse installs, and facilitate switching |
| between workspaces. [Platform Core, Platform UI] [Themes: User experience] |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37681">37681</a>) <em><img src="ok.gif" width="12" height="12"> |
| Work completed</em></p> |
| <p><b>Add cheat sheets. </b> A cheat sheet is an instance of a simple kind of |
| workflow support used to help the user carry out a sequence of steps. For |
| example, "create and deploy a plug-in" is a multi-step process that |
| could be made easier to follow if there was a guide, similar to a recipe that |
| would track the user's progress and provide both descriptive text that explains |
| the steps involved and integration with Eclipse to automate the process. The |
| Welcome Page editor is a simple example of a cheat sheet. Provide a standard |
| API for creating cheat sheets. [Platform UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36946">36946</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse Platform subproject, User Experience theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse Platform subproject, User Experience theme)</h4> |
| <blockquote> |
| <p><b>Launch Eclipse editor from outside Eclipse</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=60289">60289</a>)<br> |
| <strong>Content-type-based editor lookup </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>)<br> |
| <b>Add table of contents support to wizards </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36947">36947</a>)<br> |
| <b>Add project templates </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36960">36960</a>)<br> |
| <b>Allow automation of common tasks</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37936">37936</a>)<br> |
| <b>Support workspace checkpoint and rollback </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36958">36958</a>)<br> |
| <strong>Display HTML help infopops </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37677">37677</a>)<br> |
| <b>Add capabilities </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36959">36959</a>)<br> |
| <strong>Improve local history </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37679">37679</a>)<br> |
| <strong>Add Eclipse automation </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37680">37680</a>)<br> |
| <b>Aid ongoing learning</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37666">37666</a>)<br> |
| <b>Provide a general purpose navigator</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36961">36961</a>)</p> |
| </blockquote> |
| <h3><a name="ThemeResponsiveUI">Theme: Responsive UI</a></h3> |
| <p>Making it easier to write Eclipse plug-ins that keep the UI responsive. Areas |
| for improvement run the gamut from the UI becoming sluggish (or temporarily |
| freezing) when blocking operations are done in the UI thread, to long-running |
| operations like builds and searches which could be performed in the background |
| while the user continues to work.</p> |
| <h4>Committed Items (Eclipse Platform subproject, Responsive UI theme)</h4> |
| <blockquote> |
| <p><b>Support concurrent activities.</b> In Eclipse 2.0 and 2.1, certain operations |
| like builds and searches always run synchronously and block the user at the |
| UI from doing work until the build has completed. The Eclipse Platform should |
| support operations running asynchronously in the background, so that the user |
| is not forced to be entirely idle while long-running operations are in progress. |
| This will likely require an improved concurrency architecture with more explicit |
| rules. [Platform UI, Platform Core, Platform Text, JDT Core, JDT UI, PDE] |
| [Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36957">36957</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><b>Improve update manager search.</b> Update manager searches for new and |
| updated features are done in the Eclipse client. These searches, which can |
| be time- consuming, are done only on request, and the user cannot do anything |
| in Eclipse until the search has completed. There are several ways update manager |
| searches could be improved: provide update search APIs; allow searches to |
| run asynchronously in the background; allow background searches to be scheduled |
| periodically, or on startup; allow searches to be done on the server, thereby |
| enabling sites to provide custom search implementations. [Platform Update] |
| [Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37684">37684</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Improve scalability for large help books.</strong> Improve scalability |
| for large help books. Although the help system does deal well with large collections |
| of topics distributed across many books, browser performance degrades severely |
| when a large number of topics (2000+) are concentrated in a single book. This |
| performance problem needs to be addressed, possibly by lazily loading navigation |
| information. [Platform Help] [Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37685">37685</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p>(<img border="0" src="new.gif" width="12" height="12"> recently committed |
| item) <strong>Address platform-specific UI performance problems.</strong> |
| There is a noticeable UI performance and responsiveness difference between |
| Eclipse running on Windows and Eclipse running on Linux GTK, Linux Motif, |
| or QNX Photon, all on the same hardware, with Windows clearly outperforming |
| the others. Improvements made to SWT alone have not reduced this "performance |
| gap" enough. In order to improve Eclipse performance in the other operating |
| environments, we need to make a concerted effort to determine the root causes |
| (suspects include low-level thread scheduling and synchronization), and then |
| take steps to address them. [SWT, Platform UI] [Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37683">37683</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse Platform subproject, Responsive UI theme)</h4> |
| <p>The following work items are being actively investigated, but we are not yet |
| able to promise any solution for this release:</p> |
| <blockquote> |
| </blockquote> |
| <h4>Deferred Items (Eclipse Platform subproject, Responsive UI theme)</h4> |
| <blockquote> |
| <p>(<img border="0" src="new.gif" width="12" height="12"> recently de-committed |
| item) <strong>Establish UI responsiveness targets.</strong> Eclipse should |
| establish quantitative responsiveness targets for key user actions, such as |
| opening an editor, popping up a view context menu, switching perspectives, |
| etc. These guidelines should be supported by automated benchmarks that allow |
| the responsiveness of the Eclipse UI to be measured and tracked. [Platform, |
| JDT, PDE] [Theme: Responsive UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37682">37682</a>)</p> |
| </blockquote> |
| <h3><a name="ThemeRCP">Theme: Rich client platform</a></h3> |
| <p>Eclipse was designed as a universal tool integration platform. However, many |
| facets and components of Eclipse are not particularly specific to IDEs and make |
| equal sense in non-IDE applications (e.g., window-based GUI, plug-ins, help |
| system, update manager). Certain changes, like factoring out IDE-specific |
| facilities, would allow the Eclipse Platform to be generalized into a rich |
| client platform for building non-IDE applications.</p> |
| <h4>Committed Items (Eclipse Platform subproject, Rich Client Platform theme)</h4> |
| <blockquote> |
| <p><b>Enable Eclipse to be used as a rich client platform.</b> Eclipse was designed |
| as a universal tool integration platform. However, many facets and components |
| of Eclipse are not particularly specific to IDEs and would make equal sense |
| in non-IDE applications (e.g., window-based GUI, plug-ins, help system, update |
| manager). The Eclipse Platform should factor out and segregate IDE-specific |
| facilities (e.g., everything having to do with workspace resources) so that |
| a subset of it can be used as a rich client platform for building applications. |
| [Platform Core, Platform UI, Platform Update] [Theme: Rich client platform] |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36967">36967</a>) <em><img src="ok.gif" width="12" height="12"> |
| Work completed</em></p> |
| <p><b>Provide user settings.</b> It should be possible to store user settings |
| (preferences, compiler settings, repositories lists, etc.) that are not specific |
| to a workspace separate from the workspace, so that they can be used in other |
| workspaces or by other users. [Platform Core] [Themes: Rich client platform] |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36965">36965</a>) <em><img src="ok.gif" width="12" height="12"> |
| Work completed</em></p> |
| <p><strong>Remove configuration state from workspace metadata area.</strong> |
| Feature and plug-in configuration state is currently stored in the metadata |
| subdirectory of each workspace. This has the drawback that product configuration |
| actions done in one workspace do not carry over to other workspaces. Configuration |
| state should be moved out of the workspace into the install directory (single-user |
| installs) or to a dedicated read-write product configuration area (shared |
| multi-user installs). This would mean that configuration states would be in |
| a known location for external tools to find. Different workspaces might still |
| have different configurations, which could be achieved by referencing a named |
| configuration state stored centrally. [Platform Update] [Theme: Rich client |
| platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37686">37686</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Provide update manager operations API.</b> Most of the logic currently |
| in the update manager UI should be pushed into a new operations layer. This |
| operations layer would be to Update Core what JFace is to SWT. The APIs would |
| enable update tasks to run headless, and would enable updates to be scripted. |
| [Platform Update] [Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37688">37688</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Allow uninstalling features.</b> The update manager can disable features |
| and plug- ins, but this is done without deleting their files. The update manager |
| should keep track of the features and plug-ins that it installs, and fully |
| support uninstalling them. [Platform Update] [Theme: Rich client platform] |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37689">37689</a>) <em><img src="ok.gif" width="12" height="12"> |
| Work completed</em></p> |
| <p><strong>Support adding and removing plug-ins dynamically.</strong> Installation |
| and configuration of features and plug-ins currently only happens during Eclipse |
| Platform startup. The plug-in registry should be made dynamic so that features |
| and plug-ins can be added or removed without necessarily having to restart |
| Eclipse. This will also entail adding mechanisms for handling the arrival |
| and departure of extensions and extension points. Additional mechanisms such |
| as services will be added to support the dynamic programming model. Alternative |
| runtimes (e.g., OSGi) which offer explicit support for dynamic components |
| will also be investigated and used as appropriate. Plug-in developers will |
| likely require additional support from PDE in writing and debugging well-behaved |
| dynamic plug-ins. [Platform Core, PDE] [Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37687">37687</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Support product branding.</strong> Eclipse-based products need the |
| ability to adopt a product-specific look and/or apply corporate branding. |
| Eclipse should provide mechanisms to allow such customization. This must be |
| done in such a way that plug-ins can be developed independent of any particular |
| look, and can be shared across products with different looks. [Platform UI, |
| SWT] [Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37693">37693</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Allow plug-in deactivation.</strong> In order to scale to a large |
| number of plug-ins, Eclipse does not activate a plug-in until its code is |
| actually needed. However, once activated a plug-in remains active for the |
| remainder of the session. Unfortunately, this means that an active plug-in |
| will occupy memory space for its code and objects even if it is only used |
| occasionally. Many users have sessions lasting days or weeks, and this bloat |
| taxes processor memory and JVM performance. The analogy is a long play where |
| the actors enter the stage on cue, but cannot leave it until the play is over. |
| The Eclipse Platform should support plug-ins that can be safely deactivated |
| when the user needs to recover valuable memory space. Another alternative |
| is to provide a way to quietly shutdown and restart the Platform. [Platform |
| Core, Platform UI] [Theme: Rich client platform] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36956">36956</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse Platform subproject, Rich Client Platform theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse Platform subproject, Rich Client Platform theme)</h4> |
| <blockquote> |
| <p><strong>Add a security model </strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37692">37692</a>) |
| </blockquote> |
| <h3><a name="OtherPlatform">Other Eclipse Platform Items</a></h3> |
| <h4>Committed Items (Eclipse Platform subproject, no theme)</h4> |
| <blockquote> |
| <p><strong>Improve SWT accessibility support.</strong> In Eclipse 2.1, SWT controls |
| tap in to the MSAA 1.3 accessibility support, allowing accessible UIs to be |
| built with SWT on Windows. SWT accessibility support should be extended to |
| GTK operating environments, and updated on Windows for MSAA 2.0. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37694">37694</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Improve SWT support for right-to-left languages.</b> Allow the appropriate |
| widget orientation for right-to-left languages. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36951">36951</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Remove dependency on Xerces.</strong> The Xerces plug-in currently |
| provides XML support for the Eclipse platform. XML support is now incorporated |
| into J2SE 1.4, and the presence of the Xerces plug-in can create conflicts. |
| Eclipse Platform should consistently use the built-in XML support that ships |
| with JDK 1.4, or possibly an alternative XML parser such as <a href="http://www.xmlpull.org/">XMLPull</a> |
| which has a much smaller footprint. [Platform Core] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37696">37696</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Improve Ant.</strong> Eclipse should allow the option of running |
| Ant in a separately-specified JVM. [Ant Core, Ant UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37697">37697</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Support HTML help pages in archives.</b> A JAR or zip file is a convenient |
| way to keep the large number of HTML files of a Javadoc web together. The |
| Eclipse help system should also plug-ins to contribute (and refer to) HTML |
| pages located in archives. [Platform Help] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37698">37698</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Improve organizational control over product updates.</b> In organizations |
| where there are many users and installs of the same Eclipse product, the local |
| administrator should have ways of managing how the product installs gets updated. |
| For example, the local administrator should be able to proxy a remote update |
| site and serve up supported updates hosted locally within the organization, |
| thereby conserving bandwidth, minimizing download failures, and keeping things |
| inside the organization's firewall. [Platform Update] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37702">37702</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Provide working sets for help infocenter.</b> Persistent help working |
| sets were added in Eclipse 2.1. This support is not available is infocenters, |
| where the user must still rely on searches (which are not persisted). Persistent |
| working set support should be added to infocenters as well. [Platform Help] |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37703">37703</a>) <em><img src="ok.gif" width="12" height="12"> |
| Work completed</em></p> |
| <p><strong>Provide Swing interoperability.</strong> Eclipse plug-in developers |
| often have existing Swing-based UIs that they would like to integrate with |
| Eclipse. Eclipse should provide a wrapper that allows Swing widgets to be |
| embedded within a SWT UI. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37724">37724</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed for Windows, |
| Linux</em></p> |
| <p><strong>Support multi-instance views.</strong> The workbench should support |
| multi-instance views. A multi-instance view allows multiple instances to be |
| opened side-by-side in a workbench window. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50814">50814</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Provide forms-based UI toolkit.</strong> Eclipse should provide a |
| toolkit for building UIs similar to web page forms (a mixture of text, graphics, |
| and simple controls like combo boxes, buttons, and entry fields). This style |
| of UI is currently used for the GUI pages of PDE editors and for the Update |
| Manager view. This toolkit would be an optional component suitable for use |
| with the generic workbench in RCP configurations. [Platform UI] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50815">50815</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><b>Provide improved table and table tree widgets. </b>Eclipse customers are |
| finding that the existing table and table tree custom SWT widgets lacks required |
| functionality, exhibit undesirable layout and resizing behavior, and are generally |
| ill-suited for presenting large data models. Their largely unsuccessful attempts |
| to define their own custom table tree widget have shown it to be a very challenging |
| task requiring expert-level knowledge of SWT. SWT should provide improved |
| table and table tree widgets. [SWT, Platform UI] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37998">37998</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Port SWT to 64-bit operating environments. </strong>SWT currently |
| only runs on 32-bit operating environments. SWT should be ported to run on |
| current 64-bit operating environments. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37721">37721</a>)<em> |
| <img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Make workspace builds more scalable.</strong> Owing to the build-all-projects-one-project-at-a-time |
| nature of incremental project builders, large workspaces can take a long time |
| to build when there are extensive inter-project dependencies. The build mechanism |
| needs to be more scalable in such cases, possibly by introducing builds scoped |
| to working sets. [Platform Core, Platform UI, JDT] (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50816">50816</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Support GUI test tools.</strong> SWT should provide common facilties |
| and APIs so that GUI test tools can integrate with SWT-based UIs. [SWT] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37704">37704</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse Platform subproject, no theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse Platform subproject, no theme)</h4> |
| <blockquote> |
| <p><strong>Improve team control over resource operations</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37722">37722</a>)<br> |
| <strong>Support logical resources</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">37723</a>)<br> |
| <b>Improve structure of existing documentation </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36964">36964</a>)<br> |
| <b>Improve update manager downloading </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37699">37699</a>)<br> |
| <b>Provide one-click update for Eclipse builds </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37701">37701</a>)<br> |
| <strong>Improve team API </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37705">37705</a>)<br> |
| <strong>Support native skinning in SWT </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37706">37706</a>)<br> |
| <strong>Make SWT work in a browser</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37707">37707</a>)<br> |
| <strong>Complete Mac OS X port </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37708">37708</a>)<br> |
| <strong>Support OpenGL </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37709">37709</a>)<br> |
| <strong>Support MDI </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37710">37710</a>)<br> |
| <strong>Improve message bundles </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37712">37712</a>)<br> |
| <strong>Allow infocenter to run on existing app server </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37714">37714</a>)<br> |
| <strong>Improve plug-in registry </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37715">37715</a>)<br> |
| <strong>Provide common command infrastructure </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37716">37716</a>)<br> |
| <strong>Provide better examples and snippets </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37717">37717</a>)<br> |
| <strong>Improve support for multi-page editors </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37718">37718</a>)<br> |
| <strong>Unify editors and views </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37719">37719</a>)<br> |
| <b>Improve action contributions</b> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36968">36968</a>)<br> |
| <strong>Improve UI guidelines</strong> (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37695">37695</a>)</p> |
| </blockquote> |
| <h4>Rejected Items (Eclipse Platform subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <p>(End of items for Eclipse Platform subproject.) |
| <h2><a name="JDT">Java development tools (JDT) subproject</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. The kinds of changes under consideration for the next |
| release of JDT address two general themes. The committed, proposed, and deferred |
| plan items are grouped in sections by theme:</p> |
| <ul> |
| <li><a href="#ThemeJavaFamily">Extended Java family theme</a> - Generalizing |
| JDT to handle more than just Java source files.</li> |
| <li><a href="#ThemeJDTUserExperience">User experience theme</a> - Improving |
| JDT from the point of view of the end user writing Java code.</li> |
| </ul> |
| <p>In addition, there are important Eclipse Platform improvements that do not |
| naturally fit into either of the above themes.</p> |
| <ul> |
| <li><a href="#OtherJDT">Other JDT items</a></li> |
| </ul> |
| <h3><a name="ThemeJavaFamily">Theme: Extended Java Family</a></h3> |
| <p>Generalize JDT to handle more members of the Java family than just Java |
| source files. This includes widening to handle Java-like languages (such as JSP |
| and SQLj), and embracing non-Java files containing references to Java language |
| elements (such as plug-in manifest files and J2EE deployment descriptors).</p> |
| <h4>Committed Items (Eclipse JDT subproject, Extended Java Family theme)</h4> |
| <blockquote> |
| <p><b>Improve support for Java-like source files.</b> JSP and SQLj are two instances |
| of languages that use Java syntax. Eclipse should provide better support for |
| Java-like source files. For instance, it should be possible to index these |
| files so that Java search can find the Java declarations and references within; |
| it should be possible to use Java code assist on the Java passages; refactoring |
| should be able to take these files into account; the debugger should be able |
| to step through the Java passages (<a href="http://jcp.org/en/jsr/detail?id=045" target="_blank">JSR-045</a>); |
| error highlighting should be supported across sections; etc. [JDT Core, JDT |
| UI, JDT Debug] [Theme: Extended Java family] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36939">36939</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><b>Support Java references outside Java code.</b> References to Java elements |
| in particular classes can show up in specific kinds of non-Java source files, |
| such as plug-in manifest files (plugin.xml), extension point schema files, |
| and Java launch configurations in the workspace. These references should also |
| participate in Java operations like search, move, rename, and other refactoring |
| operations. JDT will surface APIs that enable other plug-ins to contribute |
| to and participate in these operations. [JDT Core, JDT UI, JDT Debug, PDE] |
| [Theme: Extended Java family] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37937">37937</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse JDT subproject, Extended Java Family theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse JDT subproject, Extended Java Family theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h3><a name="ThemeJDTUserExperience">Theme: User Experience</a></h3> |
| <p>Improve JDT from the point of view of the end user reading, writing, and |
| navigating in Java code.</p> |
| <h4>Committed Items (Eclipse JDT subproject, User Experience theme)</h4> |
| <blockquote> |
| <p><b>Present logical view of Java objects in debugger.</b> The current debugger |
| always presents the internal structure of Java objects. For instances of standard |
| data structures like java.util.HashMap, the Java debugger should be able to |
| present a higher level logical view of the object (i.e., to show it as a table |
| of key-to-value mappings). [JDT Debug] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36942">36942</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><b>Improve refactoring.</b> JDT should add new refactorings, such as add |
| parameter, convert constructor to factory method, and extract superclass. |
| JDT should also allow other plug-ins to contribute specialized refactoring |
| operations, and provide refactoring APIs and infrastructure to make it possible |
| for them to do so. [JDT Core, JDT UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36943">36943</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Improve code formatter.</strong> JDT should provide a new code formatter |
| implementation that is more flexible and supports many more styles. [JDT Core] |
| [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37657">37657</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| <p><strong>Improve editor code navigation.</strong> The Java editor should allow |
| the user to navigate in the type hierarchy from a selected element. For instance, |
| the editor should show override indicators (currently shown only in the outliner |
| view), and allow direct navigation to the declaration of the overridden method. |
| [JDT UI] [Theme: User experience] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37658">37658</a>)<em> |
| <img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse JDT subproject, User Experience theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse JDT subproject, User Experience theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h3><a name="OtherJDT">Other JDT Items</a></h3> |
| <h4>Committed Items (Eclipse JDT subproject, no theme)</h4> |
| <blockquote> |
| <p><strong>Improve shared working copies.</strong> There is mechanism that allows |
| working copies of source files to be analyzed in the context of the rest of |
| the Java model. Currently, shared working copies are hard to manage. Eclipse |
| should simplify the management of working copies so that they can be used |
| more transparently. [JDT Core] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37659">37659</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse JDT subproject, no theme)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse JDT subproject, no theme)</h4> |
| <blockquote> |
| <p><b>Add early support for J2SE 1.5 features.</b> The next feature release |
| of J2SE is version 1.5 ("Tiger"), targeted to ship in the first |
| half of 2004. While the contents of this release are still under discussion |
| (<a href="http://jcp.org/en/jsr/detail?id=176" target="_blank">JSR-176</a>), |
| this release is expected to contain extensions to the Java language, including |
| generic types (<a href="http://jcp.org/en/jsr/detail?id=014" target="_blank">JSR-014</a>), |
| enumerations, autoboxing, enhanced for loops, static imports (all <a href="http://jcp.org/en/jsr/detail?id=201" target="_blank">JSR-201</a>), |
| metadata facility (<a href="http://jcp.org/en/jsr/detail?id=175">JSR-175</a>), |
| and compiler APIs (<a href="http://jcp.org/en/jsr/detail?id=199" target="_blank">JSR-199</a>). |
| Supporting these new language and compiler features will require major changes |
| to the Eclipse Java compiler, JDT Core APIs, and JDT UI, and may suggest new |
| Java 1.5-specific refactorings. Although Eclipse 3.0 might ship before J2SE |
| 1.5 does, Eclipse should contain early support for J2SE 1.5 features wherever |
| possible [JDT Core, JDT UI, JDT Debug] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36938">36938</a>) |
| <em><strong>NOTE: We will continue to make available early access support |
| for J2SE 1.5 in the form of replacement JDT plug-ins that can be installed |
| into Eclipse 3.0 (<a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core-home/r3.0/main.html#updates">Cheetah |
| download page</a>). Although this item is no longer under consideration for |
| the 3.0 release, the item is still high-priority and the work is ongoing.</strong></em></p> |
| <p><b>Harmonize Java source manipulation.</b> The Java model is currently implemented |
| in terms of JDOM, an early precursor of the AST facility added in 2.0. JDT |
| will move to an AST-based implementation of the Java model, and deprecate |
| JDOM. [JDT Core] (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36941">36941</a>)</p> |
| </blockquote> |
| <h4>Rejected Items (Eclipse JDT subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <p>(End of items for Eclipse JDT subproject.) |
| <h2><a name="PDE">Plug-in development environment (PDE) subproject</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 subproject)</h4> |
| <blockquote> |
| <p><strong>Add JUnit support for testing plug-ins.</strong> PDE should include |
| JUnit-based support for testing plug-ins (an early version of this support |
| is found in the optional <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/jdt-ui-home/plugins/org.eclipse.jdt.junit/index.html">org.eclipse.pde.junit</a> |
| plug-in). (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37663">37663</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em></p> |
| <p><strong>Add support for new plug-in format.</strong> PDE should provide support |
| for developing and deploying plug-ins with explicit OSGI bundle manifests. |
| The goal is provide a seamless experience for developers working with a mix |
| of traditional and new style plug-ins. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=50921">50921</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| |
| <p><strong>Improve PDE model implementation. </strong> PDE lazily builds detailed |
| models of plug- ins, plug-in fragments, features, extension point schemas. |
| Once loaded, these models are kept in memory until shut down. This approach |
| does not scale up to working with large numbers (1000s) of plug-ins. PDE model |
| elements should be changed to use a more lightweight representation. (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37660">37660</a>) |
| <em><img src="ok.gif" width="12" height="12"> Work completed</em> </p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse PDE subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse PDE subproject)</h4> |
| <blockquote> |
| <p><b>Help developers tune plug-in performance </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36944">36944</a>)<br> |
| <b>Support context-sensitive help for plug-ins </b>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=36945">36945</a>)<br> |
| <strong>Improve PDE editors </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37661">37661</a>)<br> |
| <strong>Improve plug-in debugging </strong>(<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37662">37662</a>)</p> |
| </blockquote> |
| <h4>Rejected Items (Eclipse PDE subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <p>(End of items for Eclipse PDE subproject.) |
| |
| </body> |
| |
| </html> |