marks interesting changes since the previous
draft of January 30, 2004)Please send comments about this draft plan to the eclipse-dev@eclipse.org developer mailing list.
Last revised Wednesday, April 28, 2004 (
marks interesting changes since the previous
draft of January 30, 2004)
Please send comments about this draft plan to the eclipse-dev@eclipse.org
developer mailing list.
This document lays out the feature and API set for the next feature release of Eclipse after 2.1, designated release 3.0 (Why Eclipse "3.0"?).
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.
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.
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.
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.
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.
The current status of each plan item is noted:
The release deliverables have the same form as previous releases, namely:
Release milestone occurring at roughly 6 week intervals exist to facilitate coarse-grained planning and staging. The milestones are:
Friday May 21, 2004
- Milestone 9 (3.0 M9) - stable build - feature complete - development freeze
- lock down and testing beginsThe 3.0 release is targeted for June 2004. 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.
In order to remain current, each Eclipse release targets reasonably current versions of the underlying operating environments.
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.
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 combinations of operating system and Java 2 Platform; these are our reference platforms. 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.
Eclipse SDK 3.0 is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):
|
Eclipse Reference Platforms
|
|||
|---|---|---|---|
| Operating system | Processor architecture | Window system | Java 2 Platform |
| Microsoft Windows XP | Intel x86 | Win32 | Sun Java 2 SDK, Standard Edition, version 1.4.2_03 for Microsoft Windows |
| Microsoft Windows XP | Intel x86 | Win32 |
IBM 32-bit SDK for Windows, Java 2 Technology Edition, Version 1.4.1 |
| Red Hat Enterprise Linux WS 3 | Intel x86 | GTK | Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86 |
| Red Hat Enterprise Linux WS 3 | Intel x86 | GTK | IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition, Version 1.4.1 |
| SuSE Linux 8.2 | Intel x86 | GTK | Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86 |
| SuSE Linux 8.2 | Intel x86 | GTK | IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition, Version 1.4.1 |
| Sun Solaris 8 | SPARC | Motif | Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Solaris SPARC |
| HP HP-UX 11i | hp9000 PA-RISC |
Motif | HP-UX SDK for the Java 2 platform, version 1.4.2.00 for hp9000 PA-RISC |
| IBM AIX 5L Version 5.2 | PowerPC | Motif |
IBM 32-bit SDK for AIX, Java 2 Technology Edition, Version 1.4.1 |
| Apple Mac OS X 10.3 | PowerPC | Carbon | Java 2 Standard Edition 1.4.1 for Mac OS X |
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.
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.
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.)
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.
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.
The Eclipse SDK supports GB 18030, the new Chinese code page standard, on Windows XP and 2000, and Linux.
German and Japanese locales are tested.
SWT fully supports BIDI
on Windows (only). On Linux GTK, SWT supports entering and displaying BIDI text.
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.
Eclipse 3.0 will be compatible with Eclipse 2.0 and 2.1 to the greatest extent possible.
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 Eclipse 3.0 Porting Guide 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 Eclipse 3.0 Porting Guide 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.
API Contract Compatibility: Eclipse SDK 3.0 will be upwards contract-compatible with Eclipse SDK 2.0 and 2.1 except in those areas noted in the Eclipse 3.0 Porting Guide. 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 Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.
Binary (plug-in) Compatibility: Eclipse SDK 3.0 will be upwards binary-compatible with Eclipse SDK 2.0 and 2.1 except in those areas noted in the Eclipse 3.0 Porting Guide. 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 Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.
Source Compatibility: Eclipse SDK 3.0 will be upwards source-compatible with Eclipse SDK 2.0 or 2.1 except in the areas noted in the Eclipse 3.0 Porting Guide. 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.
Workspace Compatibility: 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.
Non-compliant usage of API's: 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 How to Use the Eclipse API for information about how to write compliant plug-ins.
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 (query bugzilla for all 3.0 plan items).
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:
In addition, there are important Eclipse Platform improvements that do not naturally fit into any of the above themes.
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.
Improve UI scalability. 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] (37929)
Work completed
Improve initial user experience. 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] (37664)
Improve UI affordances. 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] (37667)
Improve file encoding support. 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] (37933)
Evolve the Eclipse user experience. 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] (37997)
Improve keyboard bindings. 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] (37934)
Improve editor management. 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] (37670)
Improve text editor interaction. 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] (37671)
Improve text editor presentation. 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] (37672)
Improve text editor typing. 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] (37674)
Improve global text search/replace. 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] (37675)
Allow dynamic help content. 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] (37676)
Simplify update manager UI. 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] (37678)
Display HTML in a widget. 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] (36952)
(
(
(
(
(
None at this time.
(
(
Add table of contents support to wizards (36947)
Add project templates (36960)
Allow automation of common tasks (37936)
Support workspace checkpoint and rollback (36958)
Display HTML help infopops (37677)
Add capabilities (36959)
Improve local history (37679)
Add Eclipse automation (37680)
Aid ongoing learning (37666)
Provide a general purpose navigator (36961)
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.
Support concurrent activities. 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] (36957)
Establish UI responsiveness targets. 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] (37682)
Improve update manager search. 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] (37684)
Improve scalability for large help books. 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] (37685)
The following work items are being actively investigated, but we are not yet able to promise any solution for this release:
Address platform-specific UI performance problems. 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] (37683)
None at this time.
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.
Enable Eclipse to be used as a rich client platform. 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] (36967)
Provide user settings. 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] (36965)
Remove configuration state from workspace metadata area. 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] (37686)
Provide update manager operations API. 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] (37688)
Allow uninstalling features. 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] (37689)
(
(
(
None at this time.
Add a security model (37692)
Improve SWT accessibility support. 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] (37694)
Improve SWT support for right-to-left languages. Allow the appropriate widget orientation for right-to-left languages. [SWT] (36951)
Remove dependency on Xerces. 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 XMLPull which has a much smaller footprint. [Platform Core] (37696)
Improve Ant. Eclipse should allow the option of running Ant in a separately-specified JVM. [Ant Core, Ant UI] (37697)
Support HTML help pages in archives. 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] (37698)
Improve organizational control over product updates. 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] (37702)
Provide working sets for help infocenter. 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] (37703)
Provide Swing interoperability. 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] (37724)
Support multi-instance views. 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] (50814)
Provide forms-based UI toolkit. 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] (50815)
(
(
(
(
None at this time.
(
(
Improve structure of existing documentation (36964)
Improve update manager downloading (37699)
Provide one-click update for Eclipse builds (37701)
Improve team API (37705)
Support native skinning in SWT (37706)
Make SWT work in a browser (37707)
Complete Mac OS X port (37708)
Support OpenGL (37709)
Support MDI (37710)
Improve message bundles (37712)
Allow infocenter to run on existing app server (37714)
Improve plug-in registry (37715)
Provide common command infrastructure (37716)
Provide better examples and snippets (37717)
Improve support for multi-page editors (37718)
Unify editors and views (37719)
Improve action contributions (36968)
Improve UI guidelines (37695)
None at this time.
(End of items for Eclipse Platform subproject.)
Java development tools (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:
In addition, there are important Eclipse Platform improvements that do not naturally fit into either of the above themes.
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).
Improve support for Java-like source files. 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 (JSR-045); error highlighting should be supported across sections; etc. [JDT Core, JDT UI, JDT Debug] [Theme: Extended Java family] (36939)
Support Java references outside Java code. 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] (37937)
None at this time.
None at this time.
Improve JDT from the point of view of the end user reading, writing, and navigating in Java code.
Present logical view of Java objects in debugger. 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] (36942)
Improve refactoring. 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] (36943)
Improve code formatter. JDT should provide a new code formatter implementation that is more flexible and supports many more styles. [JDT Core] [Theme: User experience] (37657)
(
None at this time.
None at this time.
Improve shared working copies. 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] (37659)
None at this time.
(
Harmonize Java source manipulation. 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] (36941)
None at this time.
(End of items for Eclipse JDT subproject.)
Add JUnit support for testing plug-ins. PDE should include JUnit-based support for testing plug-ins (an early version of this support is found in the optional org.eclipse.pde.junit plug-in). (37663)
Add support for new plug-in format. 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. (50921)
(
None at this time.
Help developers tune plug-in performance (36944)
Support context-sensitive help for plug-ins (36945)
Improve PDE editors (37661)
Improve plug-in debugging (37662)
None at this time.
(End of items for Eclipse PDE subproject.)