| <!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 2.2 Plan</title> |
| |
| <link rel="stylesheet" href="../../default_style.css" type="text/css"> |
| |
| </head> |
| |
| <body> |
| |
| |
| |
| <h1> |
| |
| Eclipse Project<br> |
| |
| DRAFT 2.2 Plan</h1> |
| |
| <p>Last revised Friday, December 20, 2002 (<img border="0" src="new.gif" width="12" height="12"> |
| marks interesting changes over the <a href="http://eclipse.org/eclipse/development/eclipse_project_plan_2_1.html">2.1 |
| plan</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, designated release 2.2. |
| <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 |
| 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 |
| details (which can be hashed out elsewhere). |
| <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. |
| <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>Proposed</b> plan item - A proposal for an aspect to work on for the |
| release. After due consideration, a proposal will either be committed, |
| rejected, or deferred.</li> |
| <li><b>Committed</b> plan item - A committed plan item is one that we have decided |
| to address for the release.</li> |
| <li><b>Deferred</b> plan item - A reasonable proposal that did not make it in |
| to this release for some reason is marked as deferred with a brief note as |
| to why they were deferred. Deferred plan items may resurface as proposed 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>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 "R2_2" |
| 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> |
| |
| </ul> |
| |
| <h2><a name="Milestones"></a>Release milestones</h2> |
| |
| <p>Release milestone occurring at roughly |
| 5 week intervals exist to facilitate |
| coarse-grained planning and staging. Assuming 2.2 development commences on April 1, |
| 2003, the milestones for 2003 are:</p> |
| |
| <ul> |
| <li>Friday May 2, 2003 - Milestone 1 - (2.2 M1) - stable build reflecting progress</li> |
| <li>Friday June 6, 2003 - Milestone 2 - (2.2 M2) - stable build reflecting progress</li> |
| <li>Friday August 1, 2003 - Milestone 3 - (2.2 M3) - stable build reflecting |
| progress</li> |
| <li>Friday September 12, 2003 - Milestone 4 - (2.2 M4) - stable build reflecting |
| progress</li> |
| <li>Friday October 17, 2003 - Milestone 5 - (2.2 M5) - stable build reflecting |
| progress</li> |
| <li>Friday November 21, 2003 - Milestone 6 - (2.2 M6) - stable build reflecting |
| progress</li> |
| </ul> |
| |
| <p> (Note that the two mid-summer milestones are extended by two weeks each to |
| allow for roughly half the development team to be away on vacation.)</p> |
| |
| <p> Our target |
| is to complete 2.2 early 1Q2004. 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. <img border="0" src="new.gif" width="12" height="12"> |
| The 2.2 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>Eclipse SDK 2.2 will be tested and validated on the following Java 2 |
| Platform implementations:</p> |
| <table width="91%" border="1"> |
| <tbody> |
| <tr> |
| <td width="21%"><b>Operating system</b></td> |
| <td width="18%"><b>Processor architecture</b></td> |
| <td width="73%"><b>Java 2 Platforms</b></td> |
| </tr> |
| <tr> |
| <td width="21%" rowSpan="2">Microsoft® Windows®</td> |
| <td width="18%" rowSpan="2">Intel x86</td> |
| <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for |
| Microsoft Windows <i>[exact version TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="73%">IBM 32-bit SDK for Windows, Java 2 Technology Edition, |
| version 1.4 <i>[exact version TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="21%" rowSpan="2">Linux</td> |
| <td width="18%" rowSpan="2">Intel x86</td> |
| <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Linux |
| x86 <i>[exact version TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="73%">IBM Developer Kit for Linux, Java 2 Technology Edition, |
| version 1.4 <i>[exact version TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="21%">Sun Solaris</td> |
| <td width="18%">SPARC</td> |
| <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4 for Solaris |
| SPARC <i>[exact version TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="21%">HP HP-UX</td> |
| <td width="18%">hp9000 PA-RISC</td> |
| <td width="73%"><span class="header">HP-UX SDK for the Java 2 platform, |
| version 1.4 for hp9000 PA-RISC</span> <i>[exact version TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="21%">IBM® AIX</td> |
| <td width="18%">PowerPC</td> |
| <td width="73%">IBM Developer Kit for AIX, Java 2 Technology Edition, |
| version 1.4 <i>[exact version TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="21%">Apple® Mac® OS</td> |
| <td width="18%">PowerPC</td> |
| <td width="73%">Java 2 Standard Edition 1.4 for Mac OS X <i>[exact version |
| TBD]</i></td> |
| </tr> |
| <tr> |
| <td width="21%"><span class="title">QNX</span>®<span class="title"> |
| Neutrino</span>®<span class="title"> RTOS</span></td> |
| <td width="18%">Intel x86</td> |
| <td width="73%">IBM J9 VM for QNX <i>[exact version TBD]</i></td> |
| </tr> |
| </tbody> |
| </table> |
| <p><span class="header">The following table describes the combinations of operating |
| system and Java 2 Platform used when testing the Eclipse SDK configurations. |
| The status column indicates the level of testing: "Primary" means |
| a full tested configuration; "</span>Secondary" means a configuration |
| which is only lightly tested; "Untested" means a configuration that |
| has received no testing, but which should work; "As-is" means a configuration |
| that has received no testing, and which may or may not work. The "As-is" |
| designation is used for operating environments nearing the end of their supported |
| life; bugs that show up only in "As-is" configurations of Eclipse |
| are unlikely to get fixed.</p> |
| <table height="415" width="91%" border="1"> |
| <tbody> |
| <tr> |
| <td width="11%" height="32"><b>Window system</b></td> |
| <td width="28%" height="32"><b>Java 2 Platform<br> |
| (see above table)</b></td> |
| <td width="42%" height="32"><b>Operating Environment</b></td> |
| <td width="19%" height="32"><b>Testing Status</b></td> |
| </tr> |
| <tr> |
| <td width="11%" height="104" rowSpan="5">Win32</td> |
| <td width="28%" height="104" rowSpan="5">Windows on Intel x86</td> |
| <td width="42%" height="16">Windows XP</td> |
| <td width="19%" height="16">Primary</td> |
| </tr> |
| <tr> |
| <td width="42%" height="16">Windows 2000</td> |
| <td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12"> |
| Secondary</td> |
| </tr> |
| <tr> |
| <td width="42%" height="16">Windows ME</td> |
| <td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12"> |
| Untested</td> |
| </tr> |
| <tr> |
| <td width="42%" height="16">Windows 98SE</td> |
| <td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12"> |
| As-is</td> |
| </tr> |
| <tr> |
| <td width="42%" height="16">Windows NT</td> |
| <td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12"> |
| As-is</td> |
| </tr> |
| <tr> |
| <td width="11%" height="152" rowSpan="6">Motif</td> |
| <td width="28%" height="86" rowSpan="3"> |
| <p>Linux on Intel x86</p> |
| <p> </p> |
| </td> |
| <td width="42%" height="25">RedHat Linux x86 <i>[version TBD]</i></td> |
| <td width="19%" height="25">Primary</td> |
| </tr> |
| <tr> |
| <td width="42%" height="25">SuSE Linux x86 <i>[version TBD]</i></td> |
| <td width="19%" height="25">Primary</td> |
| </tr> |
| <tr> |
| <td width="42%" height="24">Other Linux <i>[version TBD]</i></td> |
| <td width="19%" height="24">Untested</td> |
| </tr> |
| <tr> |
| <td width="28%" height="16">Solaris on SPARC </td> |
| <td width="42%" height="16">Sun Solaris SPARC <i>[version TBD]</i></td> |
| <td width="19%" height="16">Primary</td> |
| </tr> |
| <tr> |
| <td width="28%" height="16">HP-UX on hp9000 PA-RISC</td> |
| <td width="42%" height="16">HP-UX hp9000 <i>[version TBD]</i></td> |
| <td width="19%" height="16">Primary</td> |
| </tr> |
| <tr> |
| <td width="28%" height="16">AIX on PowerPC</td> |
| <td width="42%" height="16">IBM AIX on PowerPC <i>[version TBD]</i></td> |
| <td width="19%" height="16">Primary</td> |
| </tr> |
| <tr> |
| <td width="11%" height="81" rowSpan="4">GTK</td> |
| <td width="28%" height="81" rowSpan="4">Linux on Intel x86</td> |
| </tr> |
| <tr> |
| <td height="15">RedHat Linux x86 <i>[version TBD]</i></td> |
| <td height="15">Primary</td> |
| </tr> |
| <tr> |
| <td width="42%" height="16">SuSE Linux x86 <i>[version TBD]</i></td> |
| <td width="19%" height="16">Primary</td> |
| </tr> |
| <tr> |
| <td width="42%" height="16">Other Linux <i>[version TBD]</i></td> |
| <td width="19%" height="16">Untested</td> |
| </tr> |
| <tr> |
| <td width="11%" height="16">Carbon</td> |
| <td width="28%" height="16">Mac OS X on PowerPC</td> |
| <td width="42%" height="16">Mac OS X <i>[version TBD]</i></td> |
| <td width="19%" height="16"><img border="0" src="new.gif" width="12" height="12"> |
| Primary</td> |
| </tr> |
| <tr> |
| <td width="11%" height="16"> |
| Photon®</td> |
| <td width="28%" height="16">IBM J9 VM for QNX</td> |
| <td width="42%" height="16">QNX Neutrino RTOS <i>[version TBD]</i></td> |
| <td width="19%" height="16">Primary</td> |
| </tr> |
| </tbody> |
| </table> |
| <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 2000 and XP only. Note that GB 18030 also requires locale and character |
| encoding support from the Java 2 Runtime Environment version 1.4. |
| <p>German and Japanese locales have been tested.</p> |
| <h4>BIDI support</h4> |
| <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> |
| <p><i>IMPORTANT: The above BIDI support is available only on Windows platforms.</i></p> |
| |
| <h2><a name="Compatibility"></a>Compatibility with Previous Releases</h2> |
| |
| <p> |
| |
| Eclipse 2.2 will be upwards compatible with Eclipse 2.0 and 2.1.</p> |
| |
| <h3> |
| |
| Compatibility of Release 2.2 with 2.0 and 2.1</h3> |
| |
| Eclipse SDK 2.2 will be upwards compatible with Eclipse SDK 2.0 and 2.1 to the |
| greatest extent possible. We anticipate a small number of areas where slavishly |
| maintaining compatibility would not be in the best interests of the Platform or |
| its clients. All such exceptions will be noted in the 2.2 release notes so that |
| clients can assess the impact of these changes on their plug-ins and products.<p><b>API Contract Compatibility:</b> Eclipse SDK 2.2 will be upwards contract-compatible |
| with Eclipse SDK 2.0 and 2.1 unless noted. This means that programs in full compliance |
| with contracts specified in Eclipse SDK 2.0 or 2.1 APIs will automatically be in |
| full compliance with Eclipse SDK 2.2 APIs. (API is construed broadly to |
| include such things as plug-in extension points.) Downward contract compatibility |
| is not supported. There is no guarantee that compliance with Eclipse SDK 2.2 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><b>Binary (plug-in) Compatibility:</b> Eclipse SDK 2.2 will be upwards |
| binary-compatible with Eclipse SDK 2.0 and 2.1 unless noted. This means that plug-ins |
| built for Eclipse SDK 2.0 or 2.1 will continue to work correctly in Eclipse |
| SDK 2.2 without change. Downward plug-in compatibility is not supported. Plug-ins |
| for Eclipse SDK 2.2 are unlikely to be usable in Eclipse SDK 2.0 or 2.1. Plug-ins |
| with hard-coded references in their plug-in manifest file to 2.0 or 2.1 versions of |
| prerequisite Eclipse Project plug-ins will work in 2.2 provided the version match |
| rule is "greaterOrEqual" |
| or "compatible" (the default); references |
| using "perfect" or "equivalent" match rules will be broken. 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 2.2 will be upwards source-compatible |
| with Eclipse SDK 2.0 or 2.1 unless noted. This means that source files written |
| to use Eclipse SDK 2.0 or 2.1 APIs can be successfully compiled and run against Eclipse SDK |
| 2.2 APIs. Since source incompatibilities are easy to deal with, |
| maintaining source compatibility is considered much less important than maintaining |
| contract and binary compatibility. 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 2.2 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 |
| 2.2 and upgraded to a 2.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 2.2 should provide similar upwards compatibility for their hidden and visible |
| workspace metadata created by earlier versions; 2.2 plug-in developers are responsible |
| for ensuring that their plug-ins recognize 2.2, 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 Eclipse SDK 2.2 will be unusable with an earlier version |
| of Eclipse SDK. Visible metadata files created (or overwritten) by Eclipse |
| SDK 2.2 will generally be unusable with earlier versions of Eclipse SDK. |
| <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 <a href="http://www.eclipse.org/eclipse/">Eclipse Project</a> consists of |
| 3 subprojects. Each subproject is covered in its own section: |
| <blockquote><a href="#Platform">Eclipse Platform</a><br> |
| <a href="#JDT">JDT - Java development tools</a><br> |
| <a href="#PDE">PDE - Plug-in development environment</a></blockquote> |
| |
| <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 affected by that work item (many items involve coordinated changes |
| to several components). |
| |
| <h3> |
| |
| <a name="Platform">Eclipse Platform subproject</a></h3> |
| |
| The <a href="http://www.eclipse.org/platform/index.html">Eclipse |
| Platform</a> provides the most fundamental building blocks. The following items |
| reflect new features of the Eclipse Platform, or areas where existing features |
| will be significantly reworked. |
| <h4>Committed Items (Eclipse Platform subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse Platform subproject)</h4> |
| <blockquote> |
| <p> (2.1 deferred item) <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]</p> |
| <p> (2.1 deferred item) <b>Add </b><b>table of contents support to </b><b>wi</b><b>zards.</b> |
| Extend the workbench wizard framework to allow Eclipse wizard developers to |
| provide much more substantial and significant user feedback. [Platform UI]</p> |
| <p> (2.1 deferred item) <b>Support floating toolbars and views.</b> Allow the |
| user to customize the workbench by creating floating toolbars and views. [Platform |
| UI]</p> |
| <p> (2.1 deferred item) <b>Allow editors to open files outside workspace.</b> |
| A common request is to be able to open a file that is not part of the workspace |
| using Eclipse. In addition, applications would like to provide file extension |
| associations so that double-clicking on a file in the OS desktop would open |
| the associated Eclipse editor. The operations and capabilities available on |
| these "outside of the workspace" files would need to be defined. |
| [Platform UI]</p> |
| <p> (2.1 deferred item) <b>Improve serviceability. </b>Progress was made at |
| improving serviceability in 2.0; however, additional improvements are needed, |
| particularly in dealing with error conditions and reporting them in an appropriate |
| manner. [Platform Core, SWT, Platform UI]<br> |
| <br> |
| (2.1 deferred item) <b>Improve file encoding support.</b> Eclipse 2.0 and |
| 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. |
| (Ref: <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=5399">bug 5399</a>) |
| [Platform Core, Platform UI, Text, Search, Compare, JDT UI, JDT Core]</p> |
| <p>(2.1 deferred item) <b>Improve SWT support for right-to-left languages</b>. Allow |
| the appropriate widget orientation for right-to-left languages. [SWT]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <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]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Support automation of common tasks.</b> To make it easier for users to automate |
| common and repetitive tasks, the user should have a simple way of recording the sequence of |
| actions as they perform them. The recording can be edited, saved persistently, and |
| played back under similar circumstances in the same or later session, or |
| possibly another workspace. [Platform UI, Platform Core, Platform Text, JDT |
| Core, JDT UI, PDE]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Reduce workbench clutter.</b> Despite efforts to ensure UI scalability |
| with a large bases of available tools, the Eclipse workbench still intimidates |
| many users with overly long menus and wide toolbars. This problem is acute in |
| large Eclipse-based products (e.g., IBM WebSphere Application Developer). 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]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Allow plug-in deactivation.</b> 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]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Support background 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. |
| [Platform UI, Platform Core, Platform Text, JDT Core, JDT UI, PDE]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Support workspace checkpoint and rollback.</b> Sometimes a set of |
| resource changes must be explored to see if they are possible or worthwhile. |
| When the changes do not pan out, there needs to be a way to roll back the |
| workspace to the prior state. Eclipse should support long workspace transactions |
| with the ability to checkpoint and rollback. The facility should be available to |
| users and programmatically (e.g., JDT refactoring). [Platform UI, Platform Core, |
| JDT Core, JDT UI]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Add capabilities.</b> In Eclipse 2.0 we did some early work on a |
| mechanism called "capabilities" to allow users to dynamically |
| configure project natures. The Eclipse Platform should expose this mechanism to |
| users. [Platform UI, JDT UI, PDE]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> expanded 2.1 PDE |
| deferred item) <b>Add project templates.</b> Eclipse should provide a streamlined |
| way to create projects using templates contributed by plug-ins. These project |
| templates would be able to populate the projects with stock content so that |
| projects don't start off completely empty. PDE's current mechanism should |
| be generalized, pushed down into the Platform, and put to good use by JDT. |
| [Platform UI, JDT UI, PDE UI]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Provide a general purpose navigator.</b> The Eclipse Navigator view |
| presents a view of resources in the workspace. The Eclipse Platform should |
| provide a more flexible, general purpose, extensible navigator infrastructure that |
| would make it possible to show other objects as well (like an the extended |
| physical view provided by Windows Explorer). [Platform |
| UI, JDT UI]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <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]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <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. The Eclipse Platform team will |
| work with the community to define a new custom table and table tree widgets that will meet |
| their needs. [SWT, Platform UI]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Improve structure of existing documentation.</b> The Eclipse help |
| books are currently black boxes. There is no easy way to insert additional |
| material into an existing Eclipse book, such as adding a section describing a |
| new tool. And there is no way to incorporate portions of the Eclipse books into |
| some other book. The Eclipse Platform help books should be restructured in a |
| more modular manner by making better use of existing help system capabilities. |
| [Platform, JDT, PDE, Platform Help]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Provide user preferences.</b> It should be possible to store user |
| preferences that are not specific to a workspace separate from the workspace, so |
| that they can be used in any workspace. [Platform Core, Platform UI]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Evolve the Eclipse user experience.</b> The current Eclipse GUI is |
| solidly grounded in traditional opaque, rectangular windows. Recent advances in |
| UI design improve the user experience with such things as transparent overlays |
| and associating sounds with significant events. Eclipse 2.2 should have a new |
| look that makes more effective use of the capabilities of current desktop |
| computers. [Platform UI, JDT UI, Debug UI]</p> |
| <p>(<img border="0" src="new.gif" width="12" height="12"> |
| new) <b></b> <b>Enable Eclipse to be used as a general purpose application |
| framework.</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 general purpose |
| application framework. [Platform Core, Platform UI]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Improve action contributions.</b> The current action contribution story |
| is diverse and complex, and the interactions between key bindings and retargetable actions, |
| unclear. Eclipse should unify the action contribution support, provide |
| simplified support for key bindings, and clarify the interactions between key |
| bindings and retargetable actions. Eclipse should also support new types of |
| actions contributions, such as combo boxes in toolbars, and enable additional UI customization. |
| [Platform UI]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Add a "tips & tricks" facility.</b> Eclipse should |
| provide an open, flexible mechanism for offering suggestions and tips to the |
| user for the various tools available and active in the IDE. [Platform UI]</p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse Platform subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></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.) |
| |
| |
| |
| <h3> <a name="JDT">Java development tools |
| (JDT) subproject</a></h3> |
| |
| <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. |
| <h4>Committed Items (Eclipse JDT subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse JDT subproject)</h4> |
| <blockquote> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <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. Although Eclipse 2.2 will |
| likely ship before J2SE 1.5 does, Eclipse should contain early support for |
| J2SE 1.5 features wherever possible [JDT Core, JDT UI, JDT Debug]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Improve support for Java-like source files.</b> JSP and JSQL are two |
| instances of languages that embed passages of Java language code. Eclipse |
| should provide better support for Java-like source files. For instance, |
| outline views should be able to show the hierarchy of Java elements; 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]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Support Java references from non-Java files.</b> References to Java elements in particular classes |
| can show up in specific kinds of non-Java files, such as plug-in manifest |
| files (plugin.xml). 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]<br> |
| <br> |
| (<img border="0" src="new.gif" width="12" height="12"> |
| new) <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]</p> |
| <p> |
| (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Present </b><b>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]</p> |
| <p> (<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>Provide API for refactoring</b><b>.</b> JDT should allow other plug-ins to |
| contribute specialized refactoring operations, and provide the infrastructure |
| to make it possible for them to do so. [JDT Core, JDT UI]</p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse JDT subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></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.) |
| |
| |
| |
| <h3> |
| |
| <a name="PDE">Plug-in development environment (PDE) subproject</a></h3> |
| |
| 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><i>None at this time.</i></p> |
| </blockquote> |
| <h4>Proposed Items (Eclipse PDE subproject)</h4> |
| <blockquote> |
| <p>(<img border="0" src="new.gif" width="12" height="12"> new) <b>Help developers |
| tune plug-in performance.</b> Observing and measuring the dynamic behavior |
| of a plug-in is key to developing plug-ins that perform well. PDE visualizations |
| should help the developer understand the dynamic behavior of their running |
| plug-in; e.g., reason for plug-in activation, elapse time to start up, dependent |
| plug-ins activated, etc.</p> |
| </blockquote> |
| <blockquote> |
| <p>(<img border="0" src="new.gif" width="12" height="12"> |
| new) <b>S</b><b>upport context-sensitive help for plug-ins.</b> All plug-in |
| should provide context-sensitive (F1) help for their UI components. However, |
| implementing F1 support is somewhat cumbersome and error prone. PDE should |
| provide additional support in this area, such as assigning help contexts to UI |
| elements, updating corresponding XML files, and checking consistency of context |
| ids.</p> |
| </blockquote> |
| <h4>Deferred Items (Eclipse PDE subproject)</h4> |
| <blockquote> |
| <p><i>None at this time.</i></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> |
| |