Eclipse 2006 Project Plans

This document is year two of the Eclipse Planning Council Project Plan. We welcome your feedback on the Eclipse Foundation Newsgroup.

The information in the project plans portion of the Roadmap is a snapshot of the on-going, continuously developed, project planning and reporting activities of the Eclipse projects. This year (the second version of the Roadmap), we tried to create an unified and automatic mechanism for aggregating and delivering this Roadmap information... Unfortunately, it did not happen - both the tool and the information were late (specifically, bugs 109230 and 130844) and the project status instructure files for most projects. Consequently, the information in this year's roadmap is fairly sparse - the reader is directed to the project's home pages for additional information.

Callisto

The big project planning effort this year is around the Callisto Simultaneous Release.

The goal of the Callisto Simultaneous Release is to release ten major Eclipse projects (BIRT, CDT, DTP, EMF, GEF, GMF, Platform, TPTP, WTP, VE) at the same time. We are doing this simultaneous release to support the needs of the ecosystem members who integrate Eclipse frameworks into their own software and products. While those product producers naturally accept the ultimate responsibility for their customers' experiences, Callisto's goal is to eliminate uncertainity about project version numbers, and thus to allow ecosystem members to start their own integration, cross-project, and cross-product testing efforts earlier. Callisto is about improving the productivity of the developers working on top of Eclipse frameworks by providing a more transparent and predictable development cycle; Callisto is about developers helping developers serve the whole Eclipse community.

While Callisto is about the simultaneous release of ten projects, it is is not a unification of the projects - each project remains a separate open source project operating with its own project leadership, its own committers, and its own project plan.

Individual Project Plans

The Eclipse Community is currently organized into nine top-level projects, the project plans of which are described below.

• The Eclipse Project
• The Tools Project
• Web Tools (WTP)
• Business Intelligence and Reporting (BIRT)
• Data Tools Platform
• Device Software Development Platform (DSDP)
• SOA Tools Platform
• Technology (incubation)

The Eclipse Project DRAFT 3.2 Plan

Last revised 17:03 EST Feb 14, 2006 ( marks interesting changes since the previous draft of Nov. 9, 2005)

    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 the Eclipse SDK after 3.1, designated release 3.2.

• Release deliverables
• Release milestones
• Target operating environments
• Compatibility with previous releases
• Eclipse Platform project
• Java development tools (JDT) project
• Plug-in development environment (PDE) project
• Equinox project

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 Project 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 four projects under the top level Eclipse Project. Each plan item covers a feature or API that is to be added to the Eclipse Project deliverables, or some aspect of the Eclipse Project 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 component; others may involve coordinated changes to several components; other may pervade the entire SDK. Although some plan items are for work that is more pressing than 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 tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.

The current status of each plan item is noted:

• Committed plan item - A committed plan item is one that we have decided to address for the release.
• Proposed plan item - A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it. After due consideration, a proposal will either be committed or deferred.
• Deferred 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.

Release deliverables

The release deliverables have the same form as previous releases, namely:

• Source code release for all Eclipse Project deliverables, available as versions tagged "R3_2" in the Eclipse Project CVS repository.
• Eclipse SDK (runtime binary and SDK for Platform, JDT, and PDE) (downloadable).
• Eclipse Platform (runtime binary and SDK for the Platform only) (downloadable).
• Eclipse RCP (runtime binary and SDK for the Rich Client Platform) (downloadable).
• Eclipse JDT (runtime binary and SDK for the Java Development Tools) (downloadable).
• Eclipse PDE (runtime binary and SDK for the Plug-in Development Environment) (downloadable).
• Eclipse SDK Examples (downloadable).
• SWT distribution (downloadable).
• Equinox OSGi R4 framework and assorted service implementations (downloadable).

Release milestones

Release milestones, occurring at roughly 6 week intervals, exist to facilitate coarse-grained planning and staging. The milestones are:

• Friday Aug. 12, 2005 - Milestone 1 (3.2 M1) - stable build
• Friday Sep. 23, 2005 - Milestone 2 (3.2 M2) - stable build
• Friday Nov. 4, 2005 - Milestone 3 (3.2 M3) - stable build
• Friday Dec. 16, 2005 - Milestone 4 (3.2 M4) - stable build
• Friday Feb. 17, 2006 - Milestone 5 (3.2 M5) - stable build - API complete - API freeze
• Friday Mar. 31, 2006 - Milestone 6 (3.2 M6) - stable build - feature complete - development freeze - lock down and testing begins

Our target is to complete 3.2 in late June 2006. 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.

Target Operating Environments

In order to remain current, each Eclipse release targets reasonably current 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 Platform itself. Portions of the Eclipse SDK (including the RCP base, SWT, OSGi and JDT core plug-ins) are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4, etc.). With the exception of a small set of planned features that actually require Java SE 5 APIs (most notably, the support for Annotation Processing and JUnit 4), the 3.2 release of the Eclipse Project is developed against version 1.4 of the Java 2 Platform. As such, the Eclipse Project SDK as a whole is targeted at both 1.4 and Java5 VMs, with full functionality available for 1.4 level development everywhere, and new Java5 specific capabilities available when running on a Java5 VM. Appendix 1 contains a table that indicates the class library level required for each plug-in.

There are many different implementations of the Java Platform running atop a variety of operating systems. We focus Eclipse SDK testing on a handful of popular combinations of operating system and Java 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 a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse on a reference platform.

The Eclipse SDK 3.2 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	OS version	Processor architecture	Window system	Java 2 Platform
Microsoft Windows	XP	Intel x86	Win32	Sun Java 2 Standard Edition 5.0 Update 4 Update 6 for Microsoft Windows
Microsoft Windows	XP	Intel x86	Win32	IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0
Microsoft Windows	XP	Intel x86	Win32	Sun Java 2 Standard Edition 1.4.2_10 for Microsoft Windows
Microsoft Windows	XP	Intel x86	Win32	IBM 32-bit SDK for Windows, Java 2 Technology Edition 1.4.2 service release 3
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	Sun Java 2 Standard Edition 1.4.2_10 for Linux x86
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 service release 3
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	Sun Java 2 Standard Edition 5.0 Update 4 Update 6 for Linux x86
SUSE Linux Enterprise Server	9	Intel x86	GTK	Sun Java 2 Standard Edition 1.4.2_10 for Linux x86
SUSE Linux Enterprise Server	9	Intel x86	GTK	IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 service release 3
Sun Solaris	10	SPARC	GTK	Sun Java 2 Standard Edition 1.4.2_10 for Solaris SPARC
HP HP-UX	11i	hp9000 PA-RISC	Motif	HP-UX JDK for the Java 2 Platform Standard Edition for 1.4.2_09
IBM AIX 5L	5.2	Power	Motif	IBM 32-bit SDK for AIX, Java 2 Technology Edition 1.4.2 service release 3
Apple Mac OS X	10.4	Power	Carbon	Java 2 Platform Standard Edition (J2SE) 1.4.2 service release 2 for Tiger
Red Hat Enterprise Linux	WS 4	Power	GTK	IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 3
SUSE Linux Enterprise Server	9	Power	GTK	IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 3
SUSE Linux Enterprise Server	9	Power	GTK	IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 3

Because Java 1.4.2 platforms are used for most Eclipse development, in general, 1.4.2 platforms are listed here. Of course, the teams doing Java 5 based development are using Java 5 platforms, and the specific ones that they test on are also included. We expect that Eclipse will work fine on other Java 5 VMs running on window systems supported by SWT, but can not flag these as reference platforms without significant community support for testing them.

Similarly, although untested, the Eclipse SDK should work fine on other OSes that support the same window system. For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.

An early access version of the Eclipse SDK is also available for 64-bit Linux GTK. Testing has been limited to early access 64-bit J2SEs running on x86-64 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.2 on Windows or Linux can be used to cross-develop QNX applications. (Eclipse 3.2 is unavailable on QNX because there is currently no 1.5 J2SE for QNX.)

Internationalization

The Eclipse SDK 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 (level 1), the Chinese code page standard, on Windows XP and 2000, and Linux/GTK.

German and Japanese locales are tested.

BIDI support

SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering and displaying BIDI text. Within these limitations, the Eclipse SDK tools are BIDI enabled.

Compatibility with Previous Releases

Compatibility of Release 3.2 with 3.1

Eclipse 3.2 will be compatible with Eclipse 3.1 (and, hence, with 3.0).

API Contract Compatibility: Eclipse SDK 3.2 will be upwards contract-compatible with Eclipse SDK 3.1 except in those areas noted in the Eclipse 3.2 Plug-in Migration Guide. Programs that use affected APIs and extension points will need to be ported to Eclipse SDK 3.2 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 3.2 APIs would ensure compliance with Eclipse SDK 3.1 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: Eclipse SDK 3.2 will be upwards binary-compatible with Eclipse SDK 3.1 except in those areas noted in the Eclipse 3.2 Plug-in Migration Guide. Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.2 will not be usable in Eclipse SDK 3.1. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Eclipse SDK 3.2 will be upwards source-compatible with Eclipse SDK 3.1 except in the areas noted in the Eclipse 3.2 Plug-in Migration Guide. This means that source files written to use Eclipse SDK 3.1 APIs might successfully compile and run against Eclipse SDK 3.2 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Eclipse SDK APIs, they will not be usable with an earlier version of the Eclipse SDK.

Workspace Compatibility: Eclipse SDK 3.2 will be upwards workspace-compatible with Eclipse SDK 3.1 unless noted. This means that workspaces and projects created with Eclipse SDK 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.2 and upgraded to a 3.2 workspace. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project (e.g., the .project file), which may propagate between workspaces via file copying or team repositories. Individual plug-ins developed for Eclipse SDK 3.2 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.2 plug-in developers are responsible for ensuring that their plug-ins recognize 3.1, 3.0, 2.1, and 2.0 metadata and process it appropriately. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on Eclipse 3.2 will be unusable with a product based an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.2 will generally be unusable with earlier versions of Eclipse.

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 earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Themes and Priorities

The changes under consideration for the next release of Eclipse Platform, JDT, PDE and Equinox will address major themes identified by the Eclipse Requirements Council (Themes and Priorities dated Dec. 15, 2004 - pdf). The following are especially germane to this top level project:

• Scaling Up - This refers to the need for Eclipse to deal with development and deployment on a larger and more complex scale. Increasing complexities arise from large development teams distributed in different locations, large source code bases and fragile build environments that have been developed incrementally over time, the dynamic nature of new source code bases and their interaction with configuration management, and build environments involving many different tools and build rules.
• Enterprise Ready - Eclipse should be improved to allow it to be better used by large development organizations.
• Design for Extensibility: Be a Better Platform - Within the Eclipse community, many development projects are defining new development platforms on top of the Eclipse Project deliverables. These must evolve to better support this type of usage, including providing new common infrastructure and abstraction layers needed by upper platforms and adding APIs to expose existing functionality only available internally so that upper platforms can more readily integrate with and reuse what's already there.
• Simple to Use - The Eclipse components need to not only provide the features that advanced users demand, but also be something that most users find simple to use.
• Rich Client Platform - The Eclipse RCP is a Java-based application framework for the desktop. Building on the Eclipse runtime and the modular plug-in story, it is possible to build applications ranging from command line tools to feature-rich applications that take full advantage of SWT's native platform integration and the many other reusable components.
• Appealing to the Broader Community - This theme includes work that grows deeper roots into the various OS-specific communities, spreads Eclipse to additional operating environments, virtual machines, application development and deployment lifecycles, vertical market-specific frameworks and builds bridges to other open source communities.

Each of the four projects under the top-level Eclipse Project is covered in its own section:

• Eclipse Platform project
• Java development tools (JDT) project
• Plug-in development environment (PDE) project
• Equinox project

For each project, the items listed reflect new features of Eclipse or areas where existing features will be significantly reworked. Each item indicates the components likely affected by that work item (many items involve coordinated changes to several components). Numbers in parentheses link to bugzilla problem reports for that plan item.

Eclipse Platform project

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.

Committed Items (Eclipse Platform project)

( committed) Provide more flexible workspaces. Currently in Eclipse there is a direct connection between IResources and files and directories on the local file system. Eclipse should loosen this connection, by abstracting out its dependency on java.io.File, and allowing for alternative implementations. This would enable, for example, uses where the workspace is located on a remote server, or accessed via a non-file-based API, or has a non-trivial mapping between the resources and the physical layout of the files. [Resources, Text, UI] (106176) [Theme: Design for Extensibility, Enterprise Ready]

( committed) Improve and extend the SWT widget set. Modern UI design is a constantly moving target. SWT should provide the tools needed to implement first class user interfaces. For example: sort indicators in SWT tables; improved coolbar behavior/appearance; and new controls such as collapsible groups. [SWT] (106182) [Theme: Design for Extensibility, Appealing to the Broader Community]

( committed, text changed) Address new window system capabilities. SWT's basis in native widgets is one of Eclipse's major strengths. For this to remain true, SWT must continue to grow to encompass new mainstream desktop platforms and new capabilities added to existing platforms. For the 3.2 release, SWT should provide support for Windows Vista. [SWT] (106184) [Theme: Appealing to the Broader Community]

( committed, text changed) Enhance the text editor. The Eclipse Text component provides a powerful editing framework that is useful in many contexts, but some of its capabilities are currently only available in the Java editor. The Java editor should be opened up to allow more general access to the reconciling, code assist, and template proposal mechanisms. Another enhancement to the look and feel of the editor is to show change history and comments in the editor. Other possible enhancements include improving the Find/Replace dialog and annotation roll-overs. [Text] (106194) [Theme: Design for Extensibility]

( committed) Improve task assistance in text fields. Eclipse has numerous wizards and dialogs that contain text fields where there are constraints on the values that can be entered, and often task assistance can be provided, for example, in the form of potential values. Eclipse should provide an enhanced text field that has indicators for required fields, and content assist. [UI] (106199) [Theme: Simple to Use]

( committed, text changed) Enhance the debug platform. The debug support in Eclipse is increasingly being used in areas that require more flexible mechanisms than those required by simple Java programs. Features will be provided as provisional API subject to change in a future release. Features include: a flexible element hierarchy in debug views to account for different architectures such as multi-core processors, thousands of threads, etc; asynchronous, cancellable interactions when retrieving view content and labels; model driven view updates; a debug context service allowing for retargettable debug actions, flexible view wiring and pluggable source lookup. [Debug] (106205) [Theme: Design for Extensibility, Enterprise Ready]

( committed) Provide a more customizable UI. Products often need direct control over the presence and arrangement of UI elements. Similarly, end users expect to be able to customize the UI to better match their workflow. Eclipse should enable both products and end users to have more control over the user interface. For example, the workbench layout should be made more flexible and configurable, and there should be a framework to allow better control over the presence and ordering of menu and toolbar items. [UI] (106189) [Theme: Simple to Use]

( committed) Capabilities/Perspectives/Components. The UI component has several frameworks for customizing the presentation, filtering the set of available options and supporting task-based UIs tailored to the user's role. This support should be rationalized and better documented. [UI] (80130) [Theme: Simple to Use]

( committed) Provide more support for large scale workspaces. In some situations, users have workspaces containing hundreds of projects and hundreds of thousands of files. Scoped builds and working sets have become important tools for these users, and the performance optimizations done in Eclipse 3.1 have proven helpful. Eclipse should have even more support for dealing with very large workspaces, including improved searching, filtering, working sets, and bookmarks. This goes hand-in-hand with ongoing work to discover and address performance issues. [UI, Resources] (106192) [Theme: Scaling Up, Enterprise Ready]

( committed, text changed) Improve cheat sheet support. The Eclipse cheat sheet infrastructure was implemented 3.0, but is still not widely used. For cheat sheets to be become more widely adopted, the base support should be enhanced in several ways, including: adding support for invoking commands without the need for Java programming; make cheat sheets more scalable; providing for nonlinear dependancy between steps and enhancing the implementation to support working with modal dialogs. [UA, UI] (106196) [Theme: Simple to Use, Design for Extensibility]

( committed) Support dynamic and reusable content in User Assistance components. In previous releases, Eclipse Help manipulated content as a reference. Although the representation is simple and reliable, it is difficult to tailor the content for multiple presentations, or to provide incremental content contributions, content reuse, content filtering etc. The representation for help content should be improved. Also, branding information should be separated from the rest of the content to simplify aggregating multiple contributions into larger units. These features also apply to Welcome, CheatSheets and the dynamic help view. [UA] (106201) [Theme: Design for Extensibility]

Proposed Items (Eclipse Platform project)

Support logical model integration. The Eclipse Platform supports a strong physical view of projects containing resources (files and folders) in the workspace. However, there are many situations where plug-in developers would prefer to work with a logical model that is appropriate to their domain. Eclipse should ease the task for plug-in developers who want to make logical model-aware plug-ins. To do this, Eclipse should provide more flexible mechanisms for contributing actions on models that do not have a one-to-one mapping to files on the users hard disk. This would, for example, allow a team provider's repository operations to be made available on logical artifacts. In addition, existing views like the navigator and problems view should be generalized to handle logical artifacts and, in general, there should be better control over what is displayed in views and editors based on the logical models that the end user is working on. [Resources, UI, Team] (37723) [Theme: Design for Extensibility]

Update Enhancements. As the number and range of Eclipse plug-ins continues to grow, it becomes increasingly important to have a powerful update/install story. For instance, if more information about an Eclipse install was available earlier, it would be possible to pre-validate that it would be a compatible location to install particular new features and plug-ins. This information could also be used to deal with conflicting contributions. Update should also be improved to reduce the volume of data that is transferred for a given update, and PDE should provide better tools for creating and deploying updates. [Update, Runtime, PDE] (106185) [Theme: Enterprise Ready]

Provide pervasive user-assistance search capabilities. An important element of the user-assistance support in Eclipse is the federated help search support that was added in R3.1. This support should be expanded to pull in more useful results from various sources. It should also be made more extensible to assist other information contributors, and made more pervasive in the UI. [UA] (106198) [Theme: Simple to Use]

Help System enhancements. Enhance the existing Help System functionality in several ways, including support for navigation bread crumbs, support for remote installation of Help documentation, documentation index, more extensible dynamic help view, and various other enhancements. [UA] (114243) [Theme: Design for Extensibility]

( new) Additional debug platform enhancements. The debug support in Eclipse is increasingly being used in areas that require more flexible mechanisms than those required by simple Java programs. Additional work areas include: the introduction of table trees in standard debug views for better/flexible presentation; drag and drop between all debug views; support for incremental content retrieval and virtual trees; asynchronous table view with pluggable cell editors; and multiple debug scopes/contexts to support simultaneous debugging of different applications side-by-side in different sets of debug views. [Debug] (127874) [Theme: Design for Extensibility, Enterprise Ready]

( new) Deliver support for ICU4J with the Eclipse Platform. Quality internationalization is very important in the modern software world. The ability to fully enable products and applications for double-byte and bi-directional languages is a requirement of any software platform. ICU4J (http://icu.sourceforge.net/) resolves many of the known issues with internationalization for Java, and thus adopting ICU4J will provide the Eclipse Platform with the strong internationalization support it needs to make Eclipse-based applications competitive. The first goal of this work is to make any required porting effort as minimal and straight forward as possible. In addition, we will ensure that applications that must run in constrained environments (such as embedded RCP applications) will not pay a footprint penalty if they do not need full internationalization flexibility. [All] (127876) [Theme: Design for Extensibility, Enterprise Ready]

( new) Create Universal Welcome. Since Eclipse 3.0, it is possible to create a powerful Welcome using the provided framework support. In the increasingly componentized environment, it is more and more impractical to create extensions for separate implementations in different products. Based on experience gained in creating Welcome implementations so far, a universal Welcome implementation will be provided that can be shared between many products. Universal Welcome will be customizable by both products and users, and will provide for intelligent merging of content in root pages. A selected number of root pages that can cover the needs of most products will be available. [UA] (127842) [Theme: Simple to Use, Design for Extensibility]

Deferred Items (Eclipse Platform project)

Embedding editors and views. Various problems are encountered when trying to embed editors or views within other workbench parts. For example, the current compare infrastructure requires creating a separate text editor for viewing changes between files. This is due to a limitation in the workbench that prevents editors from being embedded inside views or other controls. As a consequence, the compare editor's nested editors don't support the full set of features provided by the corresponding real content-type-specific editor. This represents a major usability problem: the user must switch to the real editor to make changes and then return to the compare view to review the changes. Eclipse should be more flexible in the ways various editors can be used and reused. The UI component model should be improved to support nesting of workbench parts, and reduce the coupling of parts to particular locations in the workbench, allowing for more flexible UI configurations. [UI, Compare, Text] (71125) [Theme: Design for Extensibility]

( deferred) Improve UI Forms. UI Forms are increasingly being used in the Eclipse user interface. The UI Form support should be improved to allow for more pervasive use in 3.2. Critical widget functionality should be moved to SWT to ensure quality and native look and feel. The remaining UI Forms code (minus FormEditor) should be pushed down into JFace so that it is available in the Eclipse workbench. [SWT, UI, UA] (106203) [Theme: Simple to Use, Design for Extensibility]

Provide a single user-assistance content delivery mechanism. In Eclipse 3.1, three different user-assistance vehicles are used to help users in various contexts: the initial user experience shows the 'Welcome' content; cheat sheets assist during long tasks; Help shows the traditional help topics. These vehicles use similar concepts but have separate/duplicate code bases. They should be reworked so that a single content delivery mechanism is used in various contexts, allowing content producers to benefit from a single way of contributing content, making all the content searchable, and making it presentable in various contexts. This should also take into account whether content is local or remote. [UA] (106200) [Theme: Design for Extensibility]

( deferred) Improve serviceability. When an end user encounters a problem with Eclipse, it is important for support teams to be able to diagnose the root cause of the failure, and identify the failing plug-in. Eclipse should have enhanced error reporting tools that make it easy for end users to report problems. Tools should be available at all times, so that knowledgeable users could diagnose unexpected behavior such as slowdowns or exceptional memory use. [Runtime, UI, SWT] (106193) [Theme: Simple to Use, Enterprise Ready]

( new, deferred) Support GB18030-2. The GB18030-2 Chinese character set is becoming increasingly important in the Java community. Eclipse should support GB18030-2 on platforms where it is supported natively. Because of the fundamental and far reaching impact of implementing this support, it is expected that it will require an SDK (and indeed entire Eclipse Foundation) wide strategy. [All] (127864) [Theme: Simple to Use, Enterprise Ready]

( deferred) Increase flexibility when building RCP applications. The Eclipse text editor should better support RCP applications, by making features like the following available to them: annotation presentation and navigation, user assigned colors and fonts, spell checking, folding, quick diff, templates, and file buffers. The Eclipse workbench layout should be further opened up to allow RCP applications to have more control over its presentation. [Text, UI] (106187) [Theme: Rich Client Platform]

(End of items for Eclipse Platform project.)

Java development tools (JDT) project

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.

Committed Items (Eclipse JDT project,)

( committed) Add support for Java SE 6 features. Java SE 6 (aka "Mustang") will likely contain improvements to javadoc tags (like @category), classfile specification updates, pluggable annotation processing APIs, and new compiler APIs, all of which will require specific support. [JDT Core, JDT UI, JDT Text, JDT Debug] (106206) [Theme: Appealing to the Broader Community]

( committed, text changed) Improve NLS tooling. The Eclipse NLS tooling should better support the new Eclipse string externalization pattern added in 3.1. [JDT Text] (106210) [Theme: Simple to use, Scaling up]

( committed, title and text changed) Split refactoring. Refactoring currently relies on a closed world assumption. This means that all of the code to be refactored must be available in the workspace when the refactoring is triggered. However for large distributed teams, the closed world approach isn't really feasible. The same is true for clients which use binary versions of libraries where API changes from one version to another. In 3.2 the closed world assumptions will be relaxed in such a way that a refactoring executed in workspace A can be "reapplied" on workspace B to refactor any remaining references to the refactored element. [JDT Core/UI] (106207) [Theme: Scaling Up].

( new) Enable compiler participation. JDT compilation technology will be opened to enable pluggable participation.Compilation takes place in various stages, such as building and editor reconciling. A participant will be able to introspect the Java code using DOM/AST API, perform semantic analysis, issue some markers and possibly generate new source files. [JDT Core, JDT UI, JDT Text] (127885) [Theme: Multi-Language Support, Enterprise Ready, Design for Extensibility]

( new) More static analysis. Code quality can be further improved by new advanced configurable compiler diagnostics, available either when building or when editing Java files. The compiler will conduct some null reference analysis in order to anticipate some NullPointerException at runtime. For cleaning up code, the compiler will detect obsolete $NON-NLS$ tags and unused break/continue label. Assigning a parameter will be configurable as a poor coding style. For assisting migrating existing code to Java 5.0, the compiler will optionally signal any reference to a raw type, not only unchecked ones. Additionally, users will be able to configure optional errors as being non fatal, and thus allow valid classfile generations. [JDT Core] (127887) [Theme: Appealing to the Broader Community]

( new) Code style clean ups. We will provide new functionality to easily establish project wide code conventions. The 'Clean up' action will take a set of files as input to analyze and offer to fix multiple code style issues at once. Examples of 'clean up' actions are the removal of unnecessary code or qualify all field accesses with 'this'; or assisting migration to Java 5.0 [JDT UI] (127888) [Theme: Simple To Use]

( new) Improve JUnit support. The JUnit view will be improved to manage more than one set of results. This will allow running multiple tests simultaneously and keep a history of test results. We will also investigate to support JUnit4 which will require the use of J2SE 5.0 in Eclipse itself. [JDT UI] (127889) [Theme: Simple To Use]

( new) Support arbitrary Java content types. Add support for compilation units with extension different than ".java". This will for example allow components like AJDT to seamlessly integrate their AspectJ ".aj" files into the Java tooling. Existing assumptions on ".java" extensions will be removed throughout the tools. [JDT UI, JDT Core, JDT Debug] (127891) [Theme: Design for Extensibility: Be a Better Platform]

( new) More refactorings. Various enhancements for existing refactorings including hierarchical package rename and delete, updating related fields, methods and locals on type rename and improved visibility adjustments on move refactorings will be implemented. Furthermore, existing refactorings will be improved to preserve API compatibility where possible (for example when renaming a method, a deprecated stub with the old signature will be generated that forwards to the new method). We will investigate in a new refactoring 'Extract super class'. [JDT UI] (127892) [Theme: Simple To Use]

( new) Improve user experience in presence of syntax errors. While editing code, all Java tools need to manipulate incomplete sources, containing many syntax errors. Though the structure of the units is usually well extracted (as demonstrated in outline view), power tooling is requiring more than just structural information; many advanced functionalities are requiring a detailed DOM AST to conduct syntax colouring, action enabling, problem highlighting, formatting, etc... New strategies will be explored to recover statements and expressions from incomplete programs and still enable creating detailed DOM AST carrying resolved binding information. All tooling will need to be calibrated to properly handle detailed recovered DOM AST. [JDT Core, JDT UI] (127895) [Theme: Simple to Use]

( new) Enhance Java infrastructure. As part of its increased support for Javadoc, the model will support extracting Javadoc from attached source or HTML. It will allow defining optional classpath entries. The codeassist engine will be support pluggable extensions which can participate and contribute new proposals and/or filter others. Codeassist will support CamelCase pattern; and provide completions on new artifacts such as Javadoc, break/continue label. [JDT Core, JDT Text] (127898) [Theme: Appealing to the Broader Community]

( new) Support for execution environments. An execution environment describes the capabilities of a Java runtime environment. For example, an execution environment may represent J2SE-1.4. The Java launching infrastructure supports an extensible set of execution environments to be contributed to the platform and for delegates to identify installed JREs compatible with an environment. This allows teams to build, run, and debug based on execution environments rather than being bound to specific installed JREs. Additionally, new APIs will allow JREs to be queried for system properties and specific JRE configurations will be able to be contributed to the set of installed JREs via an extension point. [JDT Core, JDT Debug] (127899) [Theme: Simple to Use]

Proposed Items (Eclipse JDT project)

None at this time.

Deferred Items (Eclipse JDT project)

( deferred) Implement library projects. For plug-in development, PDE distinguishes between the plug-in projects you are working on (source plug-in projects) and plug-in projects you are working with but not actually changing (binary plug-in projects). Making this distinction affords the user the benefits of having full source for everything in their workspace where it's easily browsed and searched, while permitting economies because the latter kind of projects do not actually have to be (re)compiled. This work item is to support a similar notion of library project for Java development in general. The user should be able to flag a Java project as a library project; JDT would then know how to present library projects appropriately at the UI, and how to deal with them more efficiently using generated binaries. [JDT Core, JDT UI, PDE] (80162) [Theme: Design for Extensibility]

(End of items for Eclipse JDT project.)

Plug-in development environment (PDE) project

Committed Items (Eclipse PDE project)

( committed) New source lookup for debugging Eclipse applications. The default source lookup mechanism for debugging Java applications has scalability issues since the debugger may needing to scan a list of hundreds of plug-in projects each time it look up a source file. PDE should provide its own source path computer to which the debugger can delegate the task of locating source files. In addition to faster lookups, the PDE-based approach will be better positioned to handle duplicate source files on the same source path. It would also allow the user to easily debug plug-ins against different targets without having to change the Target Platform in the preferences. [PDE, Debug, Runtime] (106212) [Theme: Scaling Up]

( committed) Improve target support. PDE manages a model of the target Eclipse for which you are developing. Targets may be complex and diverse, and switching targets or launch configurations can be expensive. PDE should be extended to support named targets and automatically track changes to the workspace. [PDE, Runtime] (106211) [Theme: Simple to Use, Enterprise Ready]

( committed) Improve PDE build. PDE Build is fundamental to how the Eclipse Platform releases are produced. It is also increasingly being used by other Eclipse projects and in the wider community. Potential improvements to PDE build include parallel cross-building, incremental building of plug-ins, increased integration with the workspace model, and support for additional repository providers. [PDE] (106214) 106214[Theme: Enterprise Ready]

Proposed Items (Eclipse PDE project)

None at this time.

Deferred Items (Eclipse PDE project)

( deferred) API-aware tools. Given the importance that the Eclipse community places on stable, robust APIs, having good support for their implementation is critical. The support within Eclipse for describing APIs should be improved, along with better tools from assisting developers to stick to APIs provided by other plug-ins. [PDE, JDT] (106213) [Theme: Enterprise Ready]

(End of items for Eclipse PDE project.)

Equinox project

Committed Items (Equinox project)

( committed) Give OSGi a first class presence on eclipse.org. Eclipse is based on an efficient, highly scalable OSGi implementation, which has always been usable as a standalone component. OSGi should have a first class presence on eclipse.org, including making it easy for developers to reuse the Eclipse OSGi implementation in their own applications. To support this, a separate OSGi download should be provided, as is done for SWT. [Runtime] (106188) [Theme: Appealing to the Broader Community, Rich Client Platform]

( committed) Refactor the runtime. The Eclipse runtime is currently one monolithic plugin that contains the extension registry, jobs, preferences, content types, application model and various helper/utility classes. Various use cases demand independent use of these facilities. The runtime should be refactored into individual bundles for the different functional areas to improve the support for specific use cases such as using the extension registry on standard OSGi systems or standalone, and better integration between the Eclipse application model and OSGi (e.g., the OSGi MEG application model). [Framework, Bundles, Runtime] (113663) [Theme: Appealing to the Broader Community, Rich Client Platform]

Proposed Items (Equinox project)

None at this time.

Deferred Items (Equinox project)

None at this time.

(End of items for Equinox project.)

Tools Project

The Tools top-level Project does not have an overall project plan.

Web Tools (WTP)

* M4  -     January 13, 2006
* M5  -     March 3, 2006 (planned API freeeze)
* M6  -     April 14, 2006 (This is Feature Freeze except for JSF and Dali). 
                           (this 4/14 date is also called both RC0 and RC1 in Callisto plan).
* RC2 -     April 28, 2006 (tiny grace period where any safe fix can be made). 
* RC3 -     May 12, 2006 (component lead approval required for all fixes)
* RC4 -     May 26, 2006 (planned code freeze, PMC approval required for all fixes)
* RC5 -     June 16, 2006 (PMC approval and adopter sign-off required for all fixes)
* RC6 -     Jume 28, 2006 Golden Master
* Release - June 30, 2006 - WTP 1.5 Release (part of the "Callisto" joint release)

Eclipse Test & Performance Tools Platform (TPTP) Project
Approved 4.2 Plan

Last revised 00:30 PST 25 January 2006 ( marks interesting changes since 4.1 Release)

    Please send comments about this plan to the tptp-pmc@eclipse.org PMC mailing list.

This document lays out the feature and API set for the TPTP 4.2 release.

• Release Deliverables
• Release Milestones
• Target Operating Environments
• Compatibility with Previous Releases
• Themes
• Projects
• Features
• Defects

The first part of this 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 four projects under the TPTP Top-Level Project.  Each plan item covers a feature or API that is to be added to TPTP, or some aspect of TPTP that is to be improved.  Each plan item has its own entry in the TPTP 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 component; others may involve coordinated changes to several components; other may pervade the entire project.

With the previous release as the starting point, this is the plan for how we will enhance and improve it.  Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.

Release Deliverables

The following release deliverables are provided:

• Runtime
• Source
• Examples
• Component Test
• Data Collection Engine for Windows (NT, 2000, XP) x86 Runtime
• Data Collection Engine for Windows (XP, Server 2003) x86/64-bit Runtime
• Data Collection Engine for Windows Server 2003 Itanium Runtime
• Data Collection Engine for Linux x86 Runtime
• Data Collection Engine for Linux x86/64-bit Runtime
• Data Collection Engine for Linux Itanium Runtime
• Data Collection Engine for Linux zSeries Runtime
• Data Collection Engine for zSeries Runtime
• Data Collection Engine for iSeries Runtime
• Data Collection Engine for Solaris Sparc Runtime
• Data Collection Engine for AIX PPC Runtime
• Data Collection Engine for Linux PPC/64-bit
• Data Collection Engine for HP-UX Runtime
• Native Logging Implementation (All platforms)
• Plugin Translatability Log

Release Milestones

The TPTP 4.2 release is targeted for general availability on 30-Jun-2006.  All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations.  Interim release milestone are planned at roughly 6 week intervals to facilitate coarse-grained planning and staging. TPTP is participating in Callisto Simultaneous Release of Eclipse projects. The list of milestones below includes all Callisto milestones of TPTP. 

For a detailed development schedule of TPTP 4.2 release, click here.

Target Operating Environments

In order to remain current, each TPTP release targets reasonably current versions of the underlying operating environments.

• Java runtime (JRE) or Java development kit (JDK) 1.4
• Eclipse SDK 3.2 for Linux (GTK) , Linux (Motif), or Windows ( prior TPTP releases dependent on Eclipse SDK 3.1.0)
• Eclipse Modeling Framework (EMF) SDK 2.2
• XML Schema Infoset Model (XSD) SDK 2.2

Most of the TPTP 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 TPTP 4.0 release 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 TPTP testing on a handful of popular combinations of operating system and Java 2 Platform; these are our reference platforms.  TPTP 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 TPTP on non-reference platforms that cannot be recreated on any reference platform will be given lower priority than problems with running TPTP on a reference platform.

TPTP SDK 4.2 is tested and validated on the following target reference platforms (this list may be updated over the course of the release cycle):

Although untested, TPTP should work fine on other OSes that support the same operating system kernel and version.

Internationalization

TPTP is designed as the basis for internationalized products. The user interface elements provided by the TPTP 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 TPTP SDK on all of the above operating environments; DBCS locales are supported by the TPTP SDK on the Windows, GTK, and Motif window systems; BIDI locales are supported by the TPTP SDK only on Windows operating environments.

The TPTP SDK supports GB 18030, the new Chinese code page standard, on Windows XP and 2000, and Linux.

TPTP supports ICU4J starting in 4.2 release. This will significantly increase the number of supportable locales. Products needing to localize to newer locales are enabled. German, Traditional Chinese, and Arabic are tested. 

Compatibility with Previous Releases

TPTP 4.2 will be compatible with TPTP 4.1.  The following specifies details of the various aspects of release compatibility.

• API Contract Compatibility: TPTP SDK 4.2 will be upwards contract-compatible with TPTP SDK 4.1. Downward contract compatibility is not supported. There is no guarantee that compliance with TPTP SDK 4.2 APIs would ensure compliance with TPTP SDK 4.0 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

• Binary (plug-in) Compatibility: TPTP SDK 4.2 will be upwards binary-compatible with TPTP SDK 4.1. Downward plug-in compatibility is not supported. Plug-ins for TPTP SDK 4.2 will not be usable in TPTP SDK 4.1. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

• Source Compatibility: TPTP SDK 4.2 will be upwards source-compatible with TPTP SDK 4.1. This means that source files written to use TPTP SDK 4.1 APIs might successfully compile and run against TPTP SDK 4.2 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new TPTP SDK APIs, they will not be usable with an earlier version of the TPTP SDK.

• Workspace Compatibility: TPTP SDK 4.2 will be upwards workspace-compatible with TPTP SDK 4.1 unless noted. This means that workspaces and projects created with TPTP SDK 4.1 can be successfully opened by TPTP SDK 4.2 and upgraded to a 4.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. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on TPTP 4.2 will be unusable with a product based an earlier version of TPTP. Visible metadata files created (or overwritten) by TPTP 4.2 will generally be unusable with earlier versions of TPTP.

• 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 TPTP 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.

Themes

The TPTP PMC adopted and specialized the following Eclipse themes which represent the key focus areas for TPTP enhancements in the year ahead.

• Scaling Up - TPTP will work to enhance the support of large data volumes and processing rates in areas such as data collection, user interface and in the persistence of trace, log and statistical models and execution histories.

• Enterprise Ready - Hooks will be provided within the TPTP infrastructure to link testing tools to requirements tracking tools and defect tracking tools, thus embedding them effectively in enterprise development cycles. Changes to the data collection layers will increase interoperability with enterprise security infrastructure. In addition, there will be progressive adoption of the TPTP tools and infrastructure as a test platform for the project itself, which is in turn likely to drive refinements into the tools. An increased focus on whole-project integration testing will ensure effective interoperability amongst all TPTP components and the rest of the Eclipse environment.

• Design for Extensibility: Be a Better Platform - There will be a wide range of activities within TPTP to externalize APIs and define extension points, making the infrastructure more flexible, and more generic in application. A good example of this is integration of TPTP with WTP and BIRT for web application testing, profiling and generation of customized reports of results.

• Embedded Development - TPTP target execution environment and remote data collection framework provide capabilities that are adapted for high-end embedded systems. TPTP will seek contributions to add support for embedded systems. We are promoting use of TPTP native logging capabilities on a number of embedded target systems.

• Rich Client Platform - TPTP will use RCP for building manual test client and other GUI-based clients in target environments.

• Simple to Use - The existing TPTP tools were conceived as samples, rather than as exemplary, they are deficient in many areas of usability and in some cases lacking in function. The plan is that within the domains which they target they will provide a high-quality user experience out of the box. We will focus on ease of use through enhanced user documentation, tutorials, white papers, demonstrations, and a wide range of enhancements to the user interface to streamline basic processes and clarify concepts and terminology. We are focused on improving as much as possible in Release 4.2, and expect need for continuing this focus beyond 4.2.

• Enable Consistent Multi-language Support - In TPTP a significant effort will be applied in extending coverage of the trace models to represent C/C++ programs and to handle protocol activity (specifically HTTP) consistently with program activity. There will also be C/C++ APIs provided to the data collection and control layers.

• Appealing to the Broader Community - A range of initiatives will be taken to broaden the community of potential and actual users of TPTP. Technically this will include additional integration of open source test tool technologies based on JUnit, and the various hooks to JUnit in the JDT, more data collection agents – particularly focusing on open source technologies, and additional operating system and hardware platforms from which data can be collected. There will be additional marketing and an extensive outreach program to the Eclipse community for additional contribution and adoption.

Projects

The TPTP project is is comprised of four, managed in a coordinated fashion, across which the plans items are allocated.  TPTP subprojects include:

• TPTP Platform Project - Provides common infrastructure in the areas of user interface, EMF based data models, data collection and communications control, as well as remote execution environments. Additionally, the Platform provides extension points for leveraging or extending these capabilities in solution specific tooling or runtimes. This includes Eclipse workbench plug-ins as well as runtime plug-ins on a target and optionally remote system.

• Testing Tools Project - Provides specializations of the TPTP Platform for testing (e.g. test editors, trace/test conversion support), and exemplary extensible tools for specific testing environments. Initially this includes three test environments: JUnit, manual, and URL testing. These specializations provide optimized editing and reporting experiences for these use cases. In the cases where a unique runtime or an implementation of a testability interface is required, it is also developed in the project. For example, the manual test execution environment provides a remotely managed user interface specifically for collecting manual test progress. This manual user interface is unique from the common execution environment for JUnit and URL testing. .

• Tracing & Profiling Tools Project - Extends the TPTP Platform with specific data collection for Java and distributed applications that populate the common trace model, additional language and protocol support is anticipated. There are also viewers and analysis services that draw data from the common trace model. Capabilities are provided to collect and analyze heap and stack information as well as generic toolkits for instrumenting running applications..

• Monitoring Tools Project - Extends the TPTP Platform for collecting, analyzing, aggregating, and visualizing data that can be captured in the log and statistical models. The typical examples are the collection of system or application resources such as CPU or memory utilization and support for the viewing, aggregation, and analysis of that data. Logs can also be transformed into a common format and model allowing for symptom and pattern analysis. The correlation of the data in these models is of particular interest when it is associated with other model instances of statistical or log data as well as traces and tests..

Features

Plan items targeted for this release represent the addition of new features or areas where existing features will be significantly reworked or enhanced.  Plan items are allocated to themes and projects indicated above.

TPTP Platform Project Plan Items
Status	Description
Committed	Dynamic Probekit and Byte Code Insertion (BCI). Until now probes are created and Java class files are instrumented statically within the Eclipse Workbench. This feature allows for dynamic instrumentation of byte code at the time of class load using a dynamic BCI technology. This will eliminate the need for copying and modifying class files (109684). [Theme: Simple to Use]
Committed	Java 2 SE Code Analysis Tool. In an effort to increase end-user tools in TPTP, a Java code review and analysis tool will be implemented using static analysis framework. A set of 70 common code analysis rules for Java 2 SE are provided as a part of the tool. 113791 [Theme: Appealing to Broader Community, Simple to Use]
Committed	Improvements to Static Analysis Framework. A number of improvements are planned for static analysis framework - support for user defined configuration parameters through new extension points and associated UI for editing them (113795), display of rule count per category and total selected in analysis dialog (113792), collection and annotation of time spent per rule and per category (113790). [Theme: Design for Extensibility: Be a Better Platform]
Committed	Support for New Target Platforms. Adding several new platforms to the list of TPTP supported platforms such as Windows and Linux operating systems on IA32 EM64T (64-bit) and Intel Itanium Processor Family hardware. Additionally adding support for latest version of current supported platforms: 108577,108578, and 108579. [Themes: Enterprise Ready, Appealing to Broader Community]
Committed	Data Aggregation in Java Trace Collector. Full execution trace is not suited for profiling larger applications over a prolonged time period. Aggregation of data is necessary to keep the size of collected data manageable. This feature will implement data aggregation algorithms in JVMPI monitor and exercise already existing model capabilities for storing such data (108646). [Theme: Enterprise Ready, Simple to Use]
Committed	Improvements to UI features. Sort by time in symptom analysis results view (102390), log table view (108363), filter log events on complex types (108371). [Theme: Simple to Use]
Committed	Performance Improvements. Several performance improvements are planned - trace model (108938), logging (112371 and 112878). [Theme: Scaling Up]
Committed	Profiler support for JVMTI. JVMTI is the new standard and replaces JMVPI which will not available starting in Java 1.6. A technology preview of JVMTI-based Java 2 SE profiler will be released. It is a brand new implementation and and represents future direction of TPTP Java profiling and tracing tools (86225). [Theme: Design for Extensibility: Be a Better Platform]
Committed	Launch UI Enhancements to support multiple agents. This is a required feature for taking advantage of the flexibility and power of JVMTI standard. A launch dialog should support ability to specify multiple agents and their configuration (93212). [Theme: Design for Extensibility: Be a Better Platform]
Investigating	Security and Dynamic Discovery API in new agent controller technology is missing implementation (95546,74579). We are investigating opportunity to reuse implementation from backward compatibility layer of the new agent controller. [Theme: Enterprise Ready]
Helpwanted	Port of TPTP Target Environment to Mac OS X. This calls for porting TPTP C/C++ implemented agent controller and data collection agents, namely JVMPI monitor and native logging to Mac OS X (68111). [Theme: Appealing to Broader Community]
Helpwanted	Port Native Logging Component to Palm, Windows Mobile, Nokia and Sony Ericsson embedded systems (111019). [Theme: Embedded Development]
Helpwanted	Link Checking Tool based on Static Analysis Framework. Enable the static analysis framework in TPTP to check for broken links in documentation. TPTP project build should be able to run the check, produce a parse-able report, and send an email automatically to all plug-in owners whose documentation contains broken links. It is desirable to support adding additional rules for checking other documentation guidelines.(107856) [Theme: Appealing to the Broader Community]

TPTP Testing Tools Project Plan Items
Status	Description
Committed	Graphical test results overview. A graphical top level summary of test results as well as certain level of details linked with the summary on overview page to be added to the current overview tab, from where user can easily navigate to details. (103539) [Theme: Simple to Use]
Committed	Navigate back to the test case from the test results. When verdicts or invocation event provides information about the test script file and line number of the invocation, Test Log Viewer should provide the function to navigate back to the code. This is especially useful when there are VP events. (103551) [Theme: Simple to Use]
Committed	Test Log viewer improved extensibility. Details view of execution event should display the properties contained by the events in the model and should also be extensible to allow customized properties. It should also be possible to add actions associated with certain execution event. An extension point can be defined to allow that. (103555) [Theme: Simple to Use]
Committed	Include a macro editor with the auto gui test suite editor. It is currently difficult to navigate through the macro of a test case. Users have reportedly copied and pasted the macro of a test case into a separate editor just so it is easier for them to edit it. The purpose of this feature is to provide better means for users to easily navigate through the macro of a test case. (110337) [Theme: Simple to Use]
Committed	Integrate the Manual Test View with the Eclipse TPTP workbench. This enhancement involves integrating the Manual Test View with the Eclipse TPTP workbench which requires the following: Port the Manual Test View to an embedded Workbench view in the TPTP Test perspective with no new functionality. Port the Manual Test View to a plug-in application (e.g. Rich Client Platform (RCP) or Generic Workbench compared to the IDE Workbench facilities defined in the org.eclipse.ui.ide plug-in) based on the OSGi Framework to provide extensibility via extension points. Provide a command line wrapper that emulates the Agent Controller environment for launching the Manual Test View independent of the Agent Controller. (121100) [Theme: Simple to Use]
Committed	Documention of the generic recording framework. Recording is one of the common starting points for creating a test for test tools. A generic recording facility can help provide a common UI interaction starting point of recording for users. The recording facility should allow other test types, recording protocols to leverage a common UI interaction (i.e., "Record a Test"). There should also be an update concerning the use of terminology to reflect usability feedback from users. (122949) [Theme: Simple to Use]
Committed	Support annotations for all ExecutionEvents. Since annotations for all ExecutionEvents are currently supported in the TPTP Test model (see class diagram for more details), this enhancement requires exposing this support to internal components and external users. That is, a schema with documentation is required for components to generate well-formed ExecutionEvents containing annotations coupled with providing support in the Test model loaders to consume ExecutionEvents with annotations. Furthermore, modifications to the Test Log view are required for external users to access annotations contained in ExecutionEvents from the UI. (76160) [Theme: Simple to Use]
Committed	Dynamic test asset deployment when test closure is not staticly definable. Enable dynamic test asset deployment when test closure is not statically definable Implement test service to allow retrieval of dependent classes or other files from workspace during test execution (87414) [Theme: Simple to Use]
Committed	Execution History Editor: Searching. Allow users to search an execution history by any of the visible attributes of a given execution event. Examples include time window, associated interaction fragment (test model element), etc. Search results should be displayed in the eclipse search view, and navigation should be provided from the search view back to the selected element in the execution history. Also allow extension point to register custom event types for searching (i.e. HTTP Request) (89341) [Theme: Simple to Use]
Investigating	Improve usuability of the TPTP test reports. The report should have a summary to show which execution histories the attempted status (wedge in pie chart)? % of attempted and not attempted and links to each. The Test Suites should be refactored by platform, and a report should display them.Some sort of way to track which build or series of build that it was run on should be available. A consolidated lists of exceptions should be displayed (defects that are blocking test success and inconclusive results, both of those by test across the project). Add the bugzilla priority and resolution status so that you have one nice page, "this is a blocking issue & here's its bugzilla status". The hierarchy of test suites should be displayed (by project, also summaries of tests vs. the long detailed). A project health page that would combine bugzilla and test results: Summary of numbers by severity/priority. (109657) [Theme: Simple to Use]
Investigating	Test Execution and Agent Data Collection. Test Harness should be able to invoke user selectable agent data collectors when test is invoked on specified machines and associate the collected data results as with the test run. These choices, including which data should be collected, needs to be persisted (with some naming scheme), so that subsequent test runs can re-use the same data collection choices (or easily edit them). (75029) [Theme: Simple to Use]
Helpwanted	Automated Documentation Generation. The purpose of this feature is to allow users to automatically generate human-readable user instructions for a use case scenario that has been recorded. This will assist technical writers in ensuring that the most up-to-date instructions along with screen captures is shipped with the product. It's purpose is to also reduce translation costs by having the macro run with different language packs as opposed to requiring a 3rd party company to translate the same set of instructions into 8 or 9 sets of different languages. (110108) [Theme: Simple to Use]
Helpwanted	Support RCP applications for recording and playing back GUI test cases. The recording infrastructure needs to be separated from the playback infrastructure. The two need to be very loosely coupled Allow users to record and play back test cases for an RCP application The user experience must be very similar to how a test case is recorded and played back in the workbench (114159) [Theme: Simple to Use]
Helpwanted	Leverage Eclipse Contexts in the Test Perspective. Contexts provide support for the programmatic display (and possible removal) of views within the perspective. This is valuable when considering a mixed-test scenario within TPTP. Some test types may have additional views that are test-type-specific and not be relevant to other tests. Supporting contexts would allow the Test Perspective to display views relevant to a selected test type (e.g., selected in the Test Navigator) and hide irrelevant views. (83782) [Theme: Simple to Use]

TPTP Tracing and Profiling Tools Project Plan Items
Status	Description
Committed	Divide the online help into documentation for users and documentation for consumers. The Foundation has asked TPTP to divide its on-line help into two categories: doc for users (developers who use TPTP to test & profile) and doc for consumers (extenders of TPTP). Both types of documentation remain in the plug-in format, but the consumer documentation should be shipped only in the SDK driver. The user documentation should remain in the binary production driver of TPTP. (109897) [Theme: Simple to Use]
Committed	ICU4J support in TPTP. Eclipse will incorporate and package ICU, however there are no packaging details as of yet. This will be in a plugin and intended for eclipse 3.2 platform. This enhancement applies to all TPTP UI, non test components. (120002) [Theme: Simple to Use]

TPTP Monitoring Tools Project Plan Items
Status	Description
Committed	Provide mechanisms for adding and launching new statistical agents. Currently, the list of statistical agents that can be launched by TPTP is hardcoded. This feature will provide an extension point and the necessary infrastructure to allow third parties to implement new statistical agents and extend the monitoring capability of TPTP. (113166) [Theme: Design for Extensibility: Be a Better Platform]
Committed	Provide authentication when monitoring remote Windows systems. Currently the Windows Perfmon Agent is able to gather statistics from a remote system other than the one it is running on. This requires that the agent has the correct authentication to access the Perfmon data on the remote system. This can be accomplished by having the user map a network drive to the target system before starting the agent. This is an inconvenient extra step required to be performed by the user. This feature will add authentication capability to the Perfmon Agent so that it can connect to the remote system on behalf of the user. (118545) [Theme: Simple to Use]
Committed	Provide a new Symptom Database editor. A new symptom specification is being introduced with the Platorm Project feature 124699. Therefore a new symptom database editor is required to create symptoms in this new format. A conversion utiltity will also be provided to convert current symptom databases to the new specification. (64800) [Theme: Appealing to the Broader Community]
Committed	Simplify Log Import User Experience. Currently, specifying multiple log files on a log import operation is difficult. The user must create a log set and add individual logs of various types to it. A support person may have received a zip file containing many logs of various types from a customer. They must unzip the file, determine which logs are of which types and create a log set for them to import them all at once. Another example of a difficult log import scenario is if a user wants to import multiple logs of the same type from different locations on the file system. Again a log set needs to be created and the individual log file need to be added to it as separate entries in the set. These log import scenarios will be simplified from a user perspective. If a zip file of log files is specified, the log set will be created automatically. The ability to specify multiple files of the same type on the Details pane will be added. (114818 and 115087) [Theme: Simple to Use]
Committed	Improve performance of local log import. Currently for a local log import GLA parses the log file into producer CommonBaseEvent objects which are then serialized into XML and converted to consumer CommonBaseEvent objects when they are loaded into the EMF model. These conversions will be eliminated by creating a new GLA formatter that generates consumer CommonBaseEvent objects directly in the EMF model. The Log Import Wizard will modify the existing adapter configuration by replacing the existing formatter and outputter components with this new formatter component. (117062 and 117068) [Theme: Scaling Up]
Committed	Provide a log file parser so TPTP can import Java Logging XML log files. A GLA parser will be created for parsing Java Logging XML log files that can be integrated with the TPTP Log Import facility to enable import of this type of log file. (77318) [Theme: Appealing to the Broader Community]
Committed	Provide ability of GLA to automatically set CommonBaseEvent sequence number value. Currently a parser writer must write a static parser class in order to set CommonBaseEvent sequence number value correctly. This feature will enable the parser writer to specify a simple rule for sequence number that will cause GLA to set the sequence value correctly based on the creationTime value. (79579) [Theme: Simple to Use]
Committed	Provide ability of GLA to filter log data in the Sensor and Extractor. Parsing log data using regular expressions can be expensive. If the log data can be filtered before reaching the Parser component of GLA less regular expression parsing is required which will improve the performance of parsing log files with GLA. This feature will provide the infrastructure in GLA that will allow parser writers to provide filter specifications or a filter exit class to the Sensor or Extractor components of GLA to filter out log data. (79565) [Theme: Scaling Up]
Committed	Provide ability to programmatically modify GLA adapter configuration. Applications can package and make use of GLA run-time and adapter configuration files to parse log files. However, to use the packaged adapter files they must be modified. For example, the adapter configuration must specify the location and name of the log file to parse. Currently, the only way to do this programmatically is by using XML parsing libraries to read and modify these XML files. To simplify adapter configuration modification, this feature will extend the current org.eclipse.hyades.logging.adapter.Adapter API to provide methods to retrieve and modify the configuration before it is executed by GLA. (96433) [Theme: Design for Extensibility: Be a Better Platform]
Committed	Simplify GLA Adapter Configuration Editor. Currently, creating a GLA adapter configuration file with the Adapter Configuration Editor to create a log parser is too complicated. It requires extensive knowledge of the GLA architecture, regular expressions, and the CommonBaseEvent schema. The Adapter Configuration Editor user interface will be simplified to make it easier to create a log parser based on a sample log file. (78319, 104487, and 106050) [Theme: Simple to Use]

Defects

In addition to the targeted features for this release, we plan to reduce the defect backlog. Defects are prioritized based on severity, age, and resource availability. We encourage users to report defects and we will do our best to fix them in priority order. We plan to reduce backlog of defects to under 350 defects (approximately 30% reduction relative to backlog at the end of  previous release).

See TPTP 4.2 Defects for a listing of already fixed defects, current defect targets and backlog.

Select "4.2 [Completed | nil| I1 | I2 | I3] bugs" tabs.

BIRT 2.1 Project Plan

Last revised January 30, 2006

Introduction

This document lays out the feature and API set for the next feature release of the Eclipse BIRT project after 2.0, designated release 2.1.

• Release deliverables
• Release milestones
• Target operating environments
• Compatibility with previous releases
• Themes
• Projects
• Defects

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, plans are posted in an embryonic form and then revised from time to time 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 projects under the Eclipse BIRT project. Each plan item covers a feature or API that is to be added, or some aspect 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.

Please send comments about this draft plan to the BIRT Developer mailing list.

Release deliverables

In order to improve the end user experience of downloading and installing BIRT, the release deliverables will be revised. Details will become available as progress is made on this project.

Release milestones

The Eclipse BIRT 2.1 release milestones will be synchronized with the Eclipse Callisto simultaneous release. The first BIRT 2.1 milestone will be designated M5 in order to synchronize with the Callisto simultaneus release numbering. 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.

Release milestones:

• Friday, March 3, 2006 BIRT 2.1 M5
• Friday, April 7, 2006 BIRT 2.1 Release Candidate 0
• Friday, April 14, 2006 BIRT 2.1 Release Candidate 1
• Friday, April 28, 2006 BIRT 2.1 Release Candidate 2
• Friday, May 12, 2006 BIRT 2.1 Release Candidate 3
• Friday, May 26, 2006 BIRT 2.1 Release Candidate 4
• Friday, June 16, 2006 BIRT 2.1 Release Candidate 5
• Wednesday, June 28, 2006 BIRT 2.1 Release Candidate 6

For information about new features assigned to each milestone please refer to the bugzilla database. The bugzilla database will be updated on an ongoing basis as the plan progresses.

Target Operating Environments

In order to remain current, each release of an Eclipse project targets reasonably current versions of underlying operating environments and other Eclipse projects on which it depends.

Most of Eclipse, and all of BIRT, is “pure” Java™ code and has no direct dependence on the underlying operating system. For BIRT, the chief dependence is on the Eclipse Platform, Graphical Editor Framework (GEF), Modeling Framework (EMF), and on the Java 2 Platform that runs it.

The Eclipse BIRT 2.1 release depends on the following compatibility stack:

• Java 2 platform Java Development Kit (JDK) 1.4.2
• Eclipse Platform Runtime Binary 3.2
• Graphical Editor Framework (GEF) Runtime 3.2
• Eclipse Modeling Framework (EMF) 2.2

The Eclipse Platform and BIRT run in a variety of operating environments. Testing is focused on a handful of popular combinations of operating system and Java 2 Platform; these are our reference platforms. Eclipse BIRT 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 BIRT on non-reference platforms that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse BIRT on a reference platform.

For BIRT 2.1, the project team plans to tests and validate the following reference platforms:

Internationalization

Eclipse is designed as the basis for internationalized products. The user interface elements provided by the various Eclipse projects, including dialogs and error messages, are externalized. The English strings for BIRT are provided as the default resource bundles. Translations are provided with this release for French (fr_FR), German (de_DE), Spanish (es_ES), Japanese (ja_JP), Simplified Chinese (zh_CN), and Korean (ko_KR).

Compatibility with Previous Releases

BIRT 2.1 will be compatible with earlier versions of BIRT to the greatest extent possible. The nature and scope of some of the key plan items for BIRT 2.1 are such that the only feasible solutions might break compatibility. In other regards, BIRT 2.1 will be compatible with 2.0 and 1.x. We also aim to minimize the effort required to port an existing plug-in to the 2.1 APIs.

Compatibility of Release 2.1 with 2.0 and 1.x

BIRT 2.1 will be compatible with BIRT 2.0 and 1.x unless noted. The detailed compatibility statement is listed below. In this statement, "BIRT" refers to all BIRT components: BIRT Report Framework, BIRT Runtime, and BIRT Chart SDK.

API Contract Compatibility: BIRT 2.1 will be upwards contract-compatible with BIRT 2.0 and 1.x to the greatest extent possible. All incompatibility exceptions will be documented. Downward contract compatibility is not supported. There is no guarantee that compliance with BIRT 2.1 APIs will ensure compliance with BIRT 2.0 or 1.x APIs. Refer to general Eclipse document on Evolving APIs for a discussion of the kinds of API changes that maintain contract compatibility.

The BIRT Chart UI API v2.1 is compatible with the v2.0 API but not compatible with the v1.x APIs due to a full redesign of the Chart UI in the BIRT 2.0 release.

Binary (plug-in) Compatibility: The BIRT 2.1 plug-in framework will be upwards binary-compatible with BIRT 2.0 and 1.x plug-ins to the greatest extent possible. Downward plug-in compatibility is not supported. Plug-ins for BIRT 2.1 will not be usable in BIRT 2.0 or 1.x. Extension plug-ins for BIRT 2.0 and 1.x will be upwards binary-compatible with BIRT 2.1.

Source Compatibility: BIRT 2.1 will be upwards source-compatible with BIRT 2.0 and 1.x to the greatest extent possible. This means that source files written to use BIRT 2.0 or 1.x APIs will successfully compile and run against BIRT 2.1 APIs. Downward source compatibility is not supported. If source files use new BIRT APIs, they will not be usable with an earlier version of BIRT.

Report Design Compatibility:BIRT 2.1 will be upwards report design compatible with BIRT 2.0 and 1.x unless noted. This means that reports created with BIRT 2.0 or 1.x can be successfully opened by BIRT 2.1 and upgraded to a 2.1 format.

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 BIRT API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases.

Themes

Continuing on the themes for previous releases of BIRT, the BIRT project's overriding release 2.1 theme remains extending the Eclipse platform to provide infrastructure and tools that allow application developers to design, deploy, generate and view reports within their applications. In this context, the BIRT project also adopts and supports key themes within the overall Eclipse planning process.

• Scaling up and Enterprise Ready The Eclipse platform 3.2 continues to improve on scalability and readiness for the enterprise. BIRT 2.1 leverages the support that 3.2 provides by ensuring that it is tested and it supports Eclipse 3.2.
• Simple to Use - BIRT 2.1 includes ease of use enhancements such as improvements to the distribution and installation of BIRT. Additionally, BIRT 2.1 continues to provide the RCP based report designer which is targeted at the report developer.
• Appeal to a Broader Community - BIRT 2.1 will broaden the appeal of BIRT by its integration with the Eclipse Callisto simultaneous release. In addition, providing support forFirefox 1.5 and JDK 5.0 for the BIRT runtime widens BIRT's appeal.

Projects

Project planning is still under way for BIRT 2.1 and this plan will be updated in the coming weeks to add new projects as they are identified. Projects already identified are:

Integration with Eclipse Callisto Simultaneous Release The goal of the Callisto Simultaneous Release is to release ten major Eclipse projects at the same time to support the needs of the ecosystem members who integrate Eclipse frameworks into their own software and products. Callisto is about developers helping developers serve the whole Eclipse community. [Theme: Appeal to a Broader Community]

Provide support for the Eclipse 3.2 Platform The BIRT 2.1 release will be tested on the Eclipse 3.2 Platform Release. [Theme: Scaling up and Enterprise Ready]

Improve distribution and installation of BIRT Users of BIRT, especially new users, can sometimes be overwhelmed by the complexity of the installation of BIRT and all the components that it depends on. This project aims to improve the end user experience of downloading and installing BIRT and all of its related components. [Theme: Simple to Use]

ICU4J Integration Integrating the International Components for Unicode for Java will enable BIRT 2.1 to work with text in any language for any place in the world. ICU4J continues to extend Java's Unicode and internationalization support, improving performance, staying current with the Unicode standard, and providing richer APIs, while remaining as compatible as possible with the original Java text and internationalization API design. [Theme: Appeal to a Broader Community]

Defects

Data Tools Platform (DTP)

Data Tools Platform (DTP) Project 1.0

SQL Development Tools Plan

Last Updated: 11/22/05

This document contains plans for the components of the SQL Development Tools for DTP 1.0. Currently, it only reflects plans through M4 (DTP 0.N).

The table below lists the deliverables planned for each milestone by component. Each component feature specifies a priority. Direct dependencies are also indicated either next to the component or feature. Click on the component to see a description of its scope and design goals.

Feature Priority:

(C ) Critical: feature is required in order to declare subcomponent completion for milestone

(H) High: very important feature, but could move out to next milestone if necessary

(M) Medium: good feature, but not necessary

(L) Low: nice to have feature, but could defer if necessary

Feature Dependencies: shown next to each feature in square brackets [ ]

[Conn] Connectivity

[DDM] Database Definition Model

[LPG] LALR Parser Generator (non-Eclipse component)

[SM] SQL Model

[SQM] SQL Query Model

Each component will have a focal point representative who will be responsible for driving the communications, design and development for that component. The focal point will interact with the other members of that team involved in the design and/or implementation and with other components as needed. Information coming from each component will be reviewed and shared with the overall project to ensure good communication, coherency and consistency.

SQL Results View

Device Software Development Platform (DSDP)

DSDP-DD Project Plan

For the first official release of the Device Debugging project, we are exclusively focused on changes in the Eclipse Debug Model (EDM) in the Platform. The changes are described in the Technical Plans section below. The EDM enhacements will be considered "experimental" given the newness of the changes. We do not anticipate needing to creation an Device Debugging specific pacakges, e.g. org.eclipse.dd.*, in the first release. In future releases, DD-specific packages will be created to augment the capabilities in the Eclipse platform with a device software specific debugger implementation and device software debugging and utility views.

Release Schedule

Detailed plans on the EDM changes are listed here. Below is a high-level list of changes on a per-milestone basis, as well as a detailed list of Memory View improvements.

• Eclipse 3.2 M3 - 4 November 2005
  
  • Eclipse Debug Model (EDM)
  • Preliminary commit of functionality. Not ready for usage.
  • Memory View
  • Improve usability - add shortcut keys, improve workflow of add memory monitors, global reset Memory Block actions, easier to toggle visibility of tree view pane, action/shorcuts to switch between memory monitors, allow to run the view without the tree view pane,
  • Address scalability issues of table renderings, allow to adjust number of bytes per line.
  
  
• Eclipse 3.2 M4 - 16 December 2005
  
  • Eclipse Debug Model (EDM)
  • Initial commit of new Eclipse Debug Model. Not stable and intended only for initial use by the DD community.
  • See development status update from 21-December-2005 meeting
  • Memory View
  • Enhancements to the framework to support EDM enhancements: Allow models to persist preferences (row / column size), Retargettable actions, (Add Memory Block action and Add Memory Rendering action), Support for Address Space, Allow models to better decorate a memory monitor. (Support for ILabelDecorator)
  • Support for flexible hierarchy in the tree view pane.
  • Provide hover support.


• Eclipse 3.2 M5 - 17 February 2006
  
  • Eclipse Debug Model (EDM)
  • Update of EDM based on DD feedback.
  • To be discussed at Toronto meeting 22/23-Febrary-2006.
  • Memory View
  • Migrate view to be asynchronous: Migrated renderings to use asynchronous table viewer. Ensure that interactions with models are done on background thread asynchronously.


• Eclipse 3.2 M6 - 31 March 2006
  
  • Eclipse Debug Model (EDM)
  • Feature complete for Eclipse 3.2 release.
  • Memory View
  • More work with migrating the table renderings to use asynchronous table viewer: Define provisional APIs. Make the view even more flexible by allow elements other than IMemoryBlockRetrieval to be the view's input.
  
  
• Eclipse 3.2 Release - June 2006
  
  • First release of experimental EDM changes for community usage and feedback.
  • Release of Memory View improvements that take advantage of the new EDM change.

Technical Plans

In the current architecture of the Eclipse Debug Platform (Eclipse 3.1 and earlier), the debug interfaces enforce a rigid debug element hierarchy (Target – Process – Thread – Stack Frame):

A debug model provides implementations of specific interfaces representing this hierarchy, e.g. IDebugTarget, and fires debug events that cause view updates, action updates, and source lookup in the IDE. Selection changes in the debug view change the active debug context, and the various debugger views, e.g. variables, are hardwired to respond to these selection changes. The Debug view also provides run-control actions such as run, step and stop, and must be open to drive the debugger.

Participants in the Device Debugging project have found the rigidity of this functionality to be inadequate for their commercial development product needs. Specifically, the following features are needed:

• A flexible debug element hierarchy
• Model driven view updates
• Asynchronous interactions between UI and debug model
• Flexible view wiring (e.g. input to variables view)
• The ability to debug multiple sessions simultaneously

In response to these needs, the Eclipse Debug Platform intends to support arbitrary debugger implementations, thereby allowing it to interact with a wide variety of embedded targets and operating systems.

Representatives from the Debug Platform team have proposed a solution involving a layer of adaptable interfaces that enable:

• Customization of view and label content
• Model driven updates
• Retargettable debugger actions

Under this proposal, the Debug Platform will provide default implementations for backward compatibility with the old debug hierarchy and behavior, but users of the platform can also override the structure and behavior of the debugger and its views for custom debugger implementations. Below we describe the three areas of customization in more detail.

Customized view and label content. In Eclipse 3.1, view context is fixed according to the standard debug model. With the proposed architecture, debugger views can be populated with customized content based on the needs of the debug model. This is handled by a Content Adapter, as show in the block diagram below.

For each debugger view, the Content Adapter is responsible for populating the nodes in the tree based on the representation that debug model would like to present. Similarly, each node has a corresponding label adapter used to generate its text. In the case of the Debug View, for example, the view could be customized to contain a new hierarchy that represents a multi-core embedded target:

Other views can be customized in a similar manner by the Content Adapter. This proposed design also introduces a Request Monitor to asynchronously process the retrieval of data from the model. The Request Monitor is a simplification of the Deferred Content Manager in Eclipse 3.1.

Model driven view updates. In Eclipse 3.1, view updates were fixed and locked to events from the standard debug model. For example, a context stopped event updates all debug views. The proposed implementation supports customized view updates, allowing the model to dictate how and what it wants to be updated using a model proxy. This also allows the user to select different update modes for different views, e.g. manual update, update only on stopped events and not when stepping, etc. This flexibility is important because in an embedded system, there is often a performance cost associated with updating data in debugger views. Model proxies interface a model with a view by firing deltas describing what elements have changed in the model and how they should be updated. Model proxies can be implemented on a per-element basis as shown below.

Debugger Actions. In Eclipse 3.1, the Debug View is solely responsible for driving the debugger: running, stopping, stepping, initiating source lookup, forcing updates of other Debug Views, etc. This is limiting for several reasons. Debugger implementers want the ability to debug without the debug view open, to debug multiple sessions simultaneously, and to retarget debugger actions based on the custom implementation of the debug model. The proposed solution moves control of debugging from the Debug View itself to a Debug Context Manager. This manager can be driven by selection changes from the Debug View or can be driven programmatically, and the various debugger actions target the active context.

In summary this new architecture provides:

• Flexible element hierarchies/content per element, per view
• Customized labels per element, per view
• Pluggable model proxies per element, per view
• Extensible update policies per view
• Pluggable source lookup
• Retargettable debug actions
• Flexible view wiring
• Debugging without the debug view
• Debugging simultaneous sessions in different views

See Also

Please see the tutorial section of the Device Debugging project pages for more presentations and documentation.

DSDP - Target Management Draft 1.0 Plan

Last revised 12:00 CET Feb. 27, 2006 ( marks interesting recent changes)

Please send comments about this draft plan to the dsdp-tm-dev@eclipse.org developer mailing list.

This document lays out the feature and API set for the initial release of the Eclipse DSDP - Target Management Project, Remote Systems Explorer (RSE) version 1.0.0.

The Remote Systems Explorer is a Tool and Framework for working with remote computer systems. It forms the first release out of the DSDP - Target Management Project, to be augmented by additional plug-ins for device specific connection schemes and tasks in the future.

• Release deliverables
• Release milestones
• Operating environments
• Compatibility and dependencies
• Features and capabilities

This project plan and associated requirements are the result of an open and transparent process and includes input from those who have expressed an interest in the project. That said, the success of the project and its deliverables is solely dependent upon the contributions from its community membership. If you are interested in contributing to the project in the delivery of its stated goals, you are more than welcome!

The first part of the plan deals with the important matters of release deliverables, release milestones, operating environments, compatibilities and dependencies. 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 themes for the project's milestones, with more detail on these and future capabilities found on the project requirements document. Each plan item covers a feature or API that is to be added to the Remote Systems Explorer, or some aspect of the project that is to be improved.

As this plan represents the goals for the initial release of the Remote Systems Explorer, it is expected and hoped that the project will acquire additional requirements, a vibrant user community, and most importantly, a plug-in developer community to utilize the RSE framework for creating additional connection protocols, subsystem visualizers and more. With this, it is expected that the plan will be adjusted during the development cycle in order to accomodate the community to as great an extent as possible.

Release deliverables

The release deliverables have the same form as is found in most Eclipse projects, namely:

• Remote Systems Explorer source code release, available as versions tagged "R1_0" in the project's RSE CVS Repository and TM Core CVS Repository .
• Remote Systems Explorer SDK (includes runtime, user and programmer documentation, with sources) (downloadable).
• Remote Systems Explorer runtime binary distribution (includes user documentation) (downloadable).
• Remote Systems Explorer examples (downloadable).
• Remote Systems Explorer unit tests (downloadable).

Release milestones

Release milestone will be occurring at roughly 6 week intervals. The milestones are:

• TBD - Milestone 0 (1.0 M0) - build machine in place
• Friday April 7, 2006 - Milestone 1 (1.0 M1) - stable build
• Friday May 19, 2006 - Milestone 2 (1.0 M2) - stable build
• Friday June 30, 2006 - Milestone 3 (1.0 M3) - stable build (API freeze)
• Friday August 11, 2006 - Milestone 4 (1.0 M4/RC0) - stable build

Lock down and testing then begins with M4, and progress through a series of test-fix passes against candidates releases. Release candidate builds are planned as follows (M4 is release candidate 0):

• Friday August 25, 2006 - Release Candidate 1 - (1.0 RC1)
• Friday September 8, 2006 - Release Candidate 2 - (1.0 RC2)
• Friday September 22, 2006 - Release Candidate 3 - (1.0 RC3)

As soon as no critical problems are found in the two-week testing period between two release candidates, a release candidate can be declared the release.

All release deliverables will be available for download as soon as the release has been tested and validated in the operating environments listed below.

Operating Environments

In order to remain current, each Eclipse release is designed to run on reasonably current versions of the underlying operating environments.

The Remote Systems Explorer depends upon on the Eclipse Platform. For this release, the RSE sources will be written and compiled against version 1.4.2 of the Java Platform APIs (i.e., Java 2 Platform, Release 1.4.2 SE), and designed to run on version 1.4.2 of the Java Runtime Environment, Standard Edition. Since Java 5 is also used as Eclipse Reference Platform, some testing of RSE will also be done on Java 5.

Eclipse Platform SDK 3.2 will be tested and validated on a number of reference platforms (this list is updated over the course of the release cycle). The Remote Systems Explorer wil be tested and validated against a subset of those listed for the platform, plus some more (marked ) for which contributors have have expressed special interest and volunteered to perform the systematic testing:

Remote Systems Explorer Reference Platforms
Operating system	OS version	Processor architecture	Window system	Java 2 Platform
Microsoft Windows	XP	Intel x86	Win32	Sun Java 2 Standard Edition 5.0 Update 6 for Microsoft Windows
Microsoft Windows	XP	Intel x86	Win32	IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0
Microsoft Windows	2000	Intel x86	Win32	Sun Java 2 Standard Edition 1.4.2_10 for Microsoft Windows
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	Sun Java 2 Standard Edition 5.0 Update 6 for Linux x86
SUSE Linux Enterprise Server	9	Intel x86	GTK	IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 service release 3
Sun Solaris	8	SPARC	Motif	Sun Java 2 Standard Edition 1.4.2_10 for Solaris SPARC
Ubuntu / Debian Linux	(TBD)	Intel x86	GTK	Sun Java 2 Standard Edition 1.4.2_10 for Linux x86

Eclipse and the RSE undoubtedly run fine in many operating environments beyond the reference platforms we test. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Eclipse on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse on a reference platform.

Internationalization

The Remote Systems Explorer is designed as the basis for internationalized products. The user interface elements provided by the RSE components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles. The default bundles will be localized to a subset of those locales offered by the Platform. This plan will be updated to indicate which locales will be provided and the timeframe for availability.

Compatibility and Dependencies

Compatibility of Release 1.0

The Remote Systems Explorer will be developed in parallel with the Eclipse Platform SDK version 3.2. Each RSE Milestone Release will be based on the most recent Platform Milestone available at the time of release. Therefore, the RSE initial release will be compatible with Eclipse Platform 3.2 release and will publish binary and source compatibilities with migration guides on subsequent releases.

API Contract

It is a goal of the Target Management Project to avoid provisional APIs. APIs published for the 1.0 release will be carefully reviewed prior to release, making use of "internal" packages for unsupported and variable implementation classes. Client plug-ins that directly depend on anything other than what is specified in the published API are inherently unsupportable and receive no guarantees about future compatibility. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Features and Capabilities

For the milestones listed in this document, a set of overall themes ("purpose") is used to indicate what major set of functionalities is to be concentrated on for each. These themes are presented below, while the requirements document and associated Bugzilla entries are left to those wanting more detailed information on each.

M0 Theme: Infrastructure in place (as soon as EMO completes IP review, + 1 week)

• Purpose: give easy access to RSE to a wider community; acquire API comments, begin prototyping; documentation feedback regarding missing or semantically incorrect instructions (but not about incorrect wording, package names etc.), get obvious bugs into Bugzilla, find client OS problems
• Deliverables: Runtime, SDK; some examples part of SDK, but no separate download yet.
• ISV Doc and User doc in its current form (marked "outdated")
• Start automated (weekly) builds
• Create Download site to give access to automated builds
• Plugin and feature versions set to 1
• Add basic framework for automated tests

M1 Theme: Functional (April 7)

• Purpose: Add required functionality to provide an environment that is complete for those applications that we currently know of.
• More Refactoring
• Wizard completely replacable
• Hide "New..." entries from the RSE tree - Register "New Connection" as a New Wizard
• Add Persistence Provider for sharing in a team (make different versions merge-able by using a scheme that is simpler than XMI)
• Write some Manual Test Plans (Scripts, what the manual testers have to do)

M2 Theme: Functional Complete (May 19)

• Purpose: More prototyping, lots of prototype and API feedback by the community, lots of bug reports
• Deliverables: Add JUnit tests to Downloads, Make separate download for examples
• More Refactoring
• Add User Actions
• Add Import / Export facility
• Telnet (contributed by WR)
• Write more Manual Test Plans (Scripts, what the manual testers have to do)
• Some automated Test Scripts
• Community Feedback on APIs, Docs

M3 Theme: API Freeze (June 30)

• Purpose: Finding & fixing bugs, prototyping, documentation feedback, use to drive future function requests (for next release), verification of extensions, usage in various different environments
• Final form for ISV Doc
• Community Feedback on APIs, Docs
• Bugfixing

M4 / RC0 Theme: Ready to Release (August 11)

• Purpose: Planned and coordinated testing on all supported reference platforms, fixing final bugs
• Final form of User Doc
• Localization and product polish

RSE Release 1.0.0: Target date September 22, 2006

SOA Tools (STP)

The SOA Tools top-level Project does not have an overall project plan.

Technology (incubator)

As it is comprised primarily of incubators, research, and education projects, the Technology project is not formally part of the Platform Release Plan.

March 7, 2006