Eclipse 2007 Project Plans

This document is year three 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 again (the third version of the Roadmap), we tried to create an unified and automatic mechanism for aggregating and delivering this Roadmap information... Once again, this automation did not happen: 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.

Europa

The big project planning effort this year is around the Europa Simultaneous Release, the follow-up to the Callisto Simultaneous Release of 2006.

The goal of the Europa Simultaneous Release is to release all the major Eclipse projects 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, Europa'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. Europa 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 Europa is about the simultaneous release of multiple 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

AJDT

Status: 1.5 planned for June 2007 (as part of the Europa Simultaneous Release)
Eclipse version: 3.3
Platforms: Windows XP, Linux, Mac OS X

Release themes:
  • Improve support for working with crosscutting changes
  • Improve support for working with pointcuts
  • Incorporate latest AspectJ release
  • Be part of the Europa Simultaneous Release
  • Support and benefit from Eclipse 3.3

BIRT Project 2.2 Plan

Last revised January 23, 2007

Introduction

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

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.2 release milestones will be synchronized with the Eclipse Europa simultaneous release. 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. Our target is to complete BIRT 2.2 in late June 2007. Additional milestones and their dates will be announced at a later date. Please revisit this page for more details on the release milestones.

  • Friday, October 17, 2006 - BIRT 2.2 M1
  • Friday, November 17, 2006 - BIRT 2.2 M2
  • Friday, December 25, 2006 - BIRT 2.2 M4
  • Friday, February 9, 2007 - BIRT 2.2 M5
  • Friday, March 23, 2007 - BIRT 2.2 M6
  • Friday, May 4, 2007 - BIRT 2.2 RC0
  • Friday, June 15, 2007 - BIRT 2.2 RC1
  • Friday, June 29, 2007 - BIRT 2.2

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.2 release depends on the following compatibility stack:

BIRT 2.2 Reference Stack for JDK 1.4.2

  • Java 2 platform Java Development Kit (JDK) 1.4.2
  • Eclipse Platform Runtime Binary 3.3
  • Graphical Editor Framework (GEF) Runtime 3.2
  • Eclipse Modeling Framework (EMF) 2.2
  • Data Tools Platform Project 1.5 (DTP)
  • Web Tools Project (WTP) 2.0

BIRT 2.2 Reference Stack for JDK 1.5

  • Java 2 platform Java Development Kit (JDK) 1.5
  • Eclipse Platform Runtime Binary 3.3
  • Graphical Editor Framework (GEF) Runtime 3.2
  • Eclipse Modeling Framework (EMF) 2.3
  • Data Tools Platform Project 1.5 (DTP)
  • Web Tools Project (WTP) 2.0

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.2, the project team plans to tests and validate the following reference platforms:

Eclipse BIRT Report Framework 2.2 and Eclipse BIRT RCP Report Designer 2.2 Reference Platforms
Operating system Processor architecture Window system Java 2 Platform
Microsoft Windows XP Intel x86 Win32 Sun Java 2 Standard Edition, version 1.4.2
Microsoft Windows 2000 Intel x86 Win32 Sun Java 2 Standard Edition, version 1.4.2
Microsoft Windows Server 2003 Intel x86 Win32 Sun Java 2 Standard Edition, version 1.4.2
Red Hat Enterprise Linux WS 3.0

Red Hat Enterprise Linux WS 4.0

Intel x86 GTK Sun Java 2 Standard Edition, version 1.4.2

Eclipse BIRT Runtime 2.2 and Eclipse BIRT Charts 2.2 Reference Platforms
Operating system Processor architecture Window system Java 2 Platform
Microsoft Windows XP Intel x86 Win32* Sun Java 2 Standard Edition, version 1.4.2, version 5.0
Microsoft Windows XP Intel x86 Win32* IBM SDK 1.4.2, 5.0
Microsoft Windows Server 2003 Intel x86 Win32* Sun Java 2 Standard Edition, version 1.4.2, version 5.0
Microsoft Windows Server 2003 Intel x86 Win32* IBM SDK 1.4.2, 5.0
Red Hat Enterprise Linux WS 3.0 Intel x86 GTK* Sun Java 2 Standard Edition, version 1.4.2, version 5.0
Red Hat Enterprise Linux WS 3.0 Intel x86 GTK* BlackDown SDK 1.4.2
SUSE Linux Enterprise Server 9 Intel x86 YaST* Sun Java 2 Standard Edition, version 1.4.2, version 5.0
SUSE Linux Enterprise Server 9 Intel x86 YaST* BlackDown SDK 1.4.2
*Window system only required when displaying charts within SWT or SWING windows.

BIRT Application Server Reference Platform
Apache Tomcat 5.0.x, 5.5.x
JBoss AS 4.0.2

BIRT JDBC Reference Platforms
MySQL Connector/J 3.x JDBC driver
Derby V10.1.2.1 JDBC driver

BIRT Browsers and Viewers Reference Platforms
Mozilla Firefox 1.5
Microsoft Internet Explorer 6.0
Adobe Acrobat Reader 7.0

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.2 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.2 are such that the only feasible solutions might break compatibility. In other regards, BIRT 2.2 will be compatible with 2.x and 1.x. We also aim to minimize the effort required to port an existing plug-in to the 2.2 APIs.

Compatibility of Release 2.2 with 2.1, 2.1.1, 2.0.x and 1.x

BIRT 2.2 will be compatible with BIRT 2.1, 2.1.1, 2.0.x 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.2 will be upwards contract-compatible with BIRT 2.1, 2.1.1, 2.0.x 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.2 APIs will ensure compliance with BIRT 2.1, 2.1.1, 2.0.x 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.2 is compatible with the v2.1, 2.1.1, 2.0.x 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.2 plug-in framework will be upwards binary-compatible with BIRT 2.1, 2.1.1, 2.0.x and 1.x plug-ins to the greatest extent possible. Downward plug-in compatibility is not supported. Plug-ins for BIRT 2.2 will not be usable in BIRT 2.1, 2.1.1, 2.0.x or 1.x. Extension plug-ins for BIRT 2.1, 2.1.1, 2.0.x and 1.x will be upwards binary-compatible with BIRT 2.2.

Source Compatibility: BIRT 2.2 will be upwards source-compatible with BIRT 2.1, 2.1.1, 2.0.x and 1.x to the greatest extent possible. This means that source files written to use BIRT 2.1, 2.1.1, 2.0.x or 1.x APIs will successfully compile and run against BIRT 2.2 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.2 will be upwards report design compatible with BIRT 2.1, 2.1.1, 2.0.x and 1.x unless noted. This means that reports created with BIRT 2.1, 2.1.1, 2.0.x or 1.x can be successfully opened by BIRT 2.2 and upgraded to a 2.2 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.2 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.3 continues to improve on scalability and readiness for the enterprise. BIRT 2.2 leverages the support that 3.3 provides by ensuring that it is tested and it supports Eclipse 3.3.
  • Simple to Use - BIRT 2.2 includes ease of use enhancements such as improvements to the BIRT report designer.
  • Appeal to a Broader Community - BIRT 2.2 will broaden the appeal of BIRT by its integration with the Eclipse Europa simultaneous release. In addition, BIRT 2.2 provides new report types via additional report items such as the Crosstab report item.

Projects

The candidate projects being considered for this release include the following list. Please note that the final list will depend on sign off from the project committers.

Data Sources

Web Service Data Source One of the key goals of BIRT is to support data access for a number of different data sources for reporting. Given the widespread popularity of web services, this project enhances the XML ODA driver to include the capability to treat web services as a data source. It also allows the report developer to specify data source parameters in order to filter the data that is fetched. [Bugzilla ID: 159490]

Extend Flat File Data Source Instead of specifying the column data types in the first row of a CSV file, this project looks at specifying the column names and their data types when defining the flat file data source. In addition, this project makes the flat file data source more flexible by allowing delimiters other than just the comma character. [Bugzilla ID: 152210]

Parameters for XML Data Sources In certain situations it is important to be able to specify parameters to an XML data source. An example of this is an XML data source that needs to fetch information from a finance web site given a certain stock ticker symbol . Without being able to specify a symbol, the data source would be at a loss to determine what is to be fetched. This project examines the capability to provide parameters to an XML data source. [Bugzilla ID: 116636]

Predicates in XML Data Sets It is not currently possible to apply predicates such as /city/[@iscapital=""Y""]/@name in order to fetch the name of a capital city using an XPath expression when defining an XML data source. This project extends the predicates that are supported in the XML data source.[Bugzilla ID: 152823]

Dynamic Reference to Connection Profile A connection profile contains all of the necessary information to allow a BIRT report to connect to a data source. BIRT supports importing a connection profile when creating a data source in a report design. However, when changes are made to a connection profile these changes are not reflected in the BIRT report. This project aims to provide the capability to store a reference to an external connection profile so that any changes made to the profile are automatically picked up by the BIRT report. This makes migration from a test to a production environment easy. [Bugzilla ID: 149945]

Boolean Data Type in Data Set In a data set, when creating a computed column it currently is not possible to specify the data type as a Boolean data type. This project will now allow the creation of Boolean type computed columns. [Bugzilla ID: 152443]

Emitters

Microsoft Word and Excel Outputs Users who receive reports often want to distribute these reports to a wider audience via email in order to share information. In the process of doing this, they may want to export the report to a common format such as MS Word or Excel, make the edits and then distribute the Word file or Excel spreadsheet. For usability, the receiver of the email would rather access the document as an MS Office file. PDF is often not an option since the user wants to make edits to the file. The MS Word and Excel report format converters approximate the look and spacing of elements in the original report to Word and Excel formats respectively. [Bugzilla ID: 159491]

XML Output With the rapid adoption of XML as the lingua franca for business information exchange, and for the exchange of information within an application, a large number of developers would like the output of a report delivered in XML. This would make it easy to integrate report content into other applications. Thus support for XML output is essential to the adoption of BIRT across a range of applications. This project provides an easy way to output a BIRT report as XML of-the-box. [Bugzilla ID: 159492]

Postscript Output The widespread availability and acceptance of PostScript has made it a language of choice for graphical output for printing applications. Providing a PostScript emitter from a BIRT report supports offloading the CPU workload involved in printing documents, transferring it to the printer. [Bugzilla ID: 158748]

Use of Eclipse 3.2 Features

This project aims to make use of the new Eclipse 3.2 SWT widgets and upgrades to the latest version of EMF. [Bugzilla ID: 159493]

Extensible Data Explorer View This project aims to make the data explorer view extensible so that custom data sources can now be made available and selected from in the Data Explorer view. [Bugzilla ID: 159495]

Improved Project Explorer View This project looks at improving the usability of the project navigator view especially since this view is not available in the RCP based designer. [Bugzilla ID: 159496]

Improved and Extensible Property Editor View This project aims to make the property editor view extensible and improves its look and feel. [Bugzilla ID: 159497]

Contributions to Eclipse's DTP Project This project will make several contributions to the DTP project. These include: 1) Enhance oda runtime API to provide generalized support of JDBC specialized features 2) Enhance oda.design utility to facilitate oda host processing of oda.design response/request 3) Extract common behavior from BIRT odaconsumer to DTP oda.consumer 4) Migrate BIRT oda.xml plugins to DTP Enablement namespace. [Bugzilla ID: 159498]

Formatting

Highlight Rule References Style Element Highlighting is a powerful way to draw attention to report items that meet certain conditions. For instance, in a product inventory report, if the inventory level of a product drops below the minimum stocking level, then that row in the report needs to be highlighted so that the consumer of the report can act on the information in a timely fashion. Instead of defining style elements in a highlighting rule, this project aims to allow the use of existing style elements in a BIRT report. This makes it easy for report developers to maintain changes to styles and highlighting rules. [Bugzilla ID: 146642]

Table of Contents Formatting The table of contents in a BIRT report currently do not support the use of styles. They also do not provide any flexibility in their layout. This project aims to allow the use of styles as well as more flexibility in the layout of the table of contents in a BIRT report. [Bugzilla ID: 159499]

Reference to External CSS file Style sheets provide an easy to use and productive mechanism to establish a uniform style across documents. This is a concept with which many users are familiar. This project extends the concept of styles to allow the definition of a style to be contained in a separate style sheet file that can be referred to from a BIRT report without importing it. This makes it easy to modify CSS files and have the changes reflected in a report design. [Bugzilla ID: 140619]

Report Item

Dynamic Crosstab Report Item A cross tabulation report (often abbreviated as a Crosstab report) displays the relation between two variables in a tabular or matrix format. An example of a crosstab report might be a “US Sales By State and Product” report that displays the US states along the X-axis and products along the Y-axis. Each cell in this table could be the sum of the amount spent by all customers who live in a particular state AND have purchased a particular product. This project aims to provide a dynamic crosstab report item where the values displayed along the rows and columns are gleaned from the data set columns. This project enhances the ODA Design API to support OLAP data source metadata to populate the crosstab report item's initial configuration. [Bugzilla ID: 102521]

Parameters

Designating Default for a List of Values Report parameters allow users to tailor the content of a report. Selecting a value for a parameter from a list of values that is fetched from a data set prevents the user from incorrectly supplying parameter values. When designing a report parameter that presents a list of values based on a data set, it is useful for the report developer to be able to examine the list and designate a default value from the list. This project aims to allow the report developer to define this default value. [Bugzilla ID: 153495]

Dataset Ad-hoc Parameters A report such as an Employee report may allow an end user to supply numerous report parameters such as first name, last name, telephone extension, office location amongst many others. Based on the values supplied by the end user the Employee report would filter the records fetched from the database using only those parameters that the end user supplied and ignoring other "unsupplied" parameters. In order to meet this requirement in BIRT currently, the report developer needs to utilize scripting. This project explores providing ad-hoc dataset parameters which in most respects behave like regular dataset parameters. They differ in that they do not have default values and if a value is not specified when a report is run then they are not used in filtering the rows fetched from a data source. Additionally, the user can specify multiple items for a single parameter. For example, the user can request all Employees located in the US or Canada. [Bugzilla ID: 142609]

Usability

Graphical Query Builder Not all report developers are familiar with SQL syntax for accessing a relational data source to retrieve data for a report. The Visual SQL Builder allows for graphical editing of SQL, increasing developer productivity, and making query construction possible for a wider user base. With a visual SQL query builder, users have the freedom to create queries without writing a single line of SQL code. The query builder is a point-and-click visual user interface that walks novice users step-by-step through the process of specifying a query that extracts data from database tables. It is expected that developers will use the visual SQL query builder for creating many of the SQL queries they need. However, for more complex queries, the developer will likely use an editor to work with the SQL directly. BIRT must support both models for working with a SQL query. [Bugzilla ID: 159501]

Debugging When designing a report the developer encounters errors occasionally. The productivity of the developer is greatly enhanced if the designer helps in pinpointing the location of that error quickly. This project looks at ways to improve this debugging capability. When the report developer clicks on a error in the Problem View, the focus would shift to the report item that has the error. If there is an error in the XML underlying the report design, then focus would shift to the line in the XML with the error. [Bugzilla ID: 159502]

Chart Designer Usability This project aims at improving the layout and general usability of the chart designer to include areas such as better grouping of data, reorganize the UI for quick access to commonly used settings, the interactivity UI, easy creation of drill-through URL's using chart values as parameters, navigation improvements, and Eclipse wizard-like error notification. [Bugzilla ID: 132040]

Ease of Plugin Development The Open Data Access (ODA) framework is key component of the Data Tools Project (DTP). ODA presents the Java developer with a robust architecture to extend the capabilities of BIRT by being able to report on custom data sources. This project will make it easier to extend the data sources that BIRT can report on by providing a wizard to create an ODA runtime and designer plugin with default implementation and stub source code. [Bugzilla ID: 159503]

Building BIRT This project focuses on making it easy for the Eclipse community to compile and build BIRT and therefore to make contributions to BIRT. [Bugzilla ID: 159504]

Quick Start to Report Development First time users and novice users of BIRT will benefit from being able to examine sample reports as they go about learning to design reports. This project looks at making a set of sample reports easily accessible by these users. [Bugzilla ID: 159505]

Improved XML Editor This project will look at improving the capabilities of the XML editor by leveraging the capabilities of the XML editor from Eclipse's Web Tools Project. [Bugzilla ID: 159507]

Improved Extensibility of Emitters BIRT provides a framework that is highly extensible. This project aims to make it easier for developers to add new types of emitters.[Bugzilla ID: 158714]

Scripting

Improved JavaScript Editor JavaScript is very approachable by a broad class of developers. This project improves the support for JavaScript in BIRT reports, including more powerful debugging capabilities. [Bugzilla ID: 159508]

Scripting Implementation This project proposes to enhance the scripting capabilities so that both Java and JavaScript based scripting utilize the same implementation and therefore have very similar levels of functionality. [Bugzilla ID: 159509]

Documentation of Scripting API's This project looks at documenting the current scripting API's for both Java and JavaScript based scripting. [Bugzilla ID: 132031]

Depoyment and Integration

Easy Deployment and Integration To encourage the use of BIRT by the development community, it must be easy for developers to integrate BIRT reports into their Java applications. To support this goal, BIRT should provide capabilities that make it easy for the developer to deploy the BIRT Runtime and reports in their application using easy-to-use tools. This project explores the use of tools from the WTP project in order to accomplish this goal. [Bugzilla ID: 159510]

JSP Tag Library for Charts Java Server Pages is a widely used technology in web application development. In order to simplify the integration of Charts within a JSP based application, this project will provide a JSP tag library. This library can be used with standalone charts as well. [Bugzilla ID: 159511]

Charting

New Chart Types This project extends the different types of charts available to include Gantt, Bubble, Difference/Range, Radar/Polar, Donut, Tubes for 2d/2d+/3d and richer Meter charts. [Bugzilla ID: 147770]

Smart Labels The layout of various chart elements becomes complicated when there are a lot of data points. This project will focus on automatically setting font sizes based on the chart size, auto wrapping, and auto positioning of X-Axis labels. [Bugzilla ID: 119068]

Scaling and Grouping This project improves the scaling and grouping of charts. Items include 2 levels X grouping (e.g. by Year and months, shown on Axis as 2 layers of labels); improved datetime and range grouping; multiple Y aggregates for X series grouping (each Y series can use its own aggregate function); multiple Y series grouping (each Y series can have its own grouping key); support linear axis for Line/Bar/Area (non-stacked) charts; datetime scaling support; overflow data handling; steps number customization; integer scale support. [Bugzilla ID: 159513]

Chart API This project aims to simplify the chart model API and make it accessible from scripting. It will only expose a set of clear interfaces that determine what can be changed using scripting. [Bugzilla ID: 159514]

Multiple Choices in Single Drill Through Action In a sales analysis report that looks at the revenue generated by various products, it is useful to present multiple options for drill down to the end user. For example, when the mouse is positioned over the revenue for Classic Cars, which contains a hyperlink, a pop-up could let the end user select either "Revenue By Region" or "Revenue By Sales Person". Selecting "Revenue By Region" would drill through to a report that presents regional distribution of revenue for Classic Cars. Selecting "Revenue By Sales Person" would drill through to a report that lists the sales persons who have sold Classic Cars. This concept would be useful for charts as well. [Bugzilla ID: 151903]

Defects

BIRT 2.2 will address defects reported by project members and the community. The list of defects targeted for resolution in BIRT 2.2 can be found in the bugzilla database on https://bugs.eclipse.org/bugs.

Buckminister

Release 1.1

Theme: Usability

  • Graphical editors for the RMAP and CSPEC
    • Use EMF for all models (awaits EMF support for generics)
    • ”Form” style editors with Eclipse look and feel
    • Intuitive and with extensive help
  • Graphical representation of a Component Model
    • Can view a complete model spanning many components
    • Should be zoomable
  • Graphical representation of the resolve process
    • Provides feedback to the user during the resolve process
    • The graph of chosen paths can be persisted
  • Standards
    • Support for Java Content Repository (JSR170)

Release 1.2

Theme: Support for wider range of component models

  • WAR and EAR recognition
    • project models produced by CSPEC actions
    • Reuse models supported by Eclipse Web Tools Project
    • Target common servers. Tomcat, Jboss, JOnAS
    • Commercial servers, such as Websphere, Weblogic, Oracle
  • Support for Ivy projects
  • Support for Java Modules (JSR277), subject to JSR finalization

Release 1.3

Theme: Support for additional languages

  • PHP/Python/Perl, C
    • Repository provider for CPAN
    • Support LAMP (Linux Apache MySQL PHP) component stack
  • Additional component models
    • Recognize CDT generated projects
    • Perhaps recognize automake/auotconf/configure projects

C/C++ Development Tooling (CDT)

Last revised: 13:18, 24 October 2006 (EDT)

CDT 4.0 is scheduled to be delivered in June 2007 as part of the Europa Simultaneous Release. Guidelines for this release are available here.

Release Deliverables

The release deliverables are the same as with previous releases.

  • Source code in CVS tagged "CDT_4_0".
  • CDT run-time, i.e. org.eclipse.cdt feature, downloadable as a tar/zip per supported platform.
  • CDT SDK, i.e. org.eclipse.cdt.sdk and org.eclipse.cdt features, downloadable as a tar/zip per supported platform.
  • Contents of SDK available from the CDT update site.
  • Contents of CDT run-time available from the Europa update site.
  • Release review slides, including project log.

Release Milestones

The CDT will follow the Europa schedule for milestones and final delivery. These generally follow the milestones of the Eclipse Platform by one week. The following are the dates for when the milestones will be generally available along with links to the plans listing the state of the CDT features for that milestone.

  • Thursday, Dec. 21, 2006 - Milestone 4 (4.0 M4) - plan.
  • Friday, Feb. 16, 2007 - Milestone 5 (4.0 M5) - plan.
  • Friday, Mar. 30, 2007 - Milestone 6 (4.0 M6) - plan - API freeze.
  • Friday, May 11, 2007 - Milestone 7 (4.0 M7) - plan - Code freeze.

The code freeze date is the RC0 date which marks the beginning of the ramp down. All features should be implemented and only bug fixes of increasing criticality should be fixed marching towards the Europa release date of Friday, June 29, 2007.

Target Operating Environments

Builds of the CDT are available for the following host operation system and architecture combinations (there are no windowing system specific plugins in the CDT):

  • Windows - x86
  • Linux - x86, x86_64, ppc, ia64
  • Mac OS X - ppc, x86 (universal)
  • Solaris - sparc
  • AIX - ppc
  • QNX Neutino - x86

The download status show that Windows x86 and Linux x86 are by far the most widely used, and, thus, tested and have the best support.

The current plan is to support Java 1.4.2 run-time environments with CDT 4.0. Some optional components will require Java 1.5.0. We are still looking for concrete examples of CDT users that can not move to Java 1.5.0. If you have such an example, please report it to cdt-dev@eclipse.org.

Plug-in Dependencies

The CDT currently only depends on the Eclipse Platform Runtime Binary. CDT 4.0 will require Eclipse 3.3.x. Since new APIs will be used, CDT 4.0 will not be compatible with Eclipse 3.2.x.

Internationalization

All effort is made to ensure that the CDT can be nationalized to all languages supported by the Eclipse Platform. Only English is provided with the CDT and is the only language known to be tested.

Compatibility with Previous Releases

The CDT has had a troubled history maintaining backwards compatibility. One of the main objectives of CDT 4.0 will be to finalize all APIs so that we can maintain backwards compatability in future releases. As such, it is anticipated that there will be more churn in the APIs for this release. All plugins that use any APIs and/or extension points provided by the CDT will need to at least recompile against CDT 4.0 and will likely need to make code changes.

Component Plans

The following are the plan items proposed for specific components of the CDT.

Core

Indexing

  • Support headless creation of indexes (PDOM), and import of these prebuilt indexes into user workspaces. bug 74433.
    • Enable pdom index files to be relocatable (contain relative or symbolic paths) bug 162172
  • Refactor the parser to allow it to be deployed as a standalone JAR file if so desired. bug 151846
  • Refactor the indexer to allow it to be deployed as a standalone JAR file if so desired. bug 158975
  • Refactor the indexer to remove hard dependencies on having an Eclipse project. bug 151847
  • Allow customizability of which parser to run on particular projects/files/resources. bug 151850

New Project Model

The main goal of the New Project Model is to increase the CDT usability, tool-integrator support and multi language support.

References:

UI

C/C++ Editor

  • Support indent width independent of tab width. Allow to specify indent width independent of tab width to support mixed-mode indentation as already requested by bug 53994 and bug 92036.
  • Default formatter. Implement a (simple) default formatter/indenter. bug 95274
  • Text Drag and Drop. Implement Text Drag and Drop for the editor. bug 78677
    Note: This may become obsolete if Eclipse platform implements it in 3.3. See also bug 11624.
  • View non-printable characters. Provide a command and toolbar button to enable visualization of non-printable characters in the editor (CR, LF, TAB, SPACE). bug 140333
    Note: This may become obsolete if Eclipse platform implements it in 3.3. See also bug 22712.
  • Auto-save. Implement an option to regularly save dirty editor buffers to the Eclipse local history as a backup mechanism. bug 140334
    See also Eclipse platform bug 34076.
  • Semantic highlighting. Colorize definitions and declarations of various C/C++ elements: function, variable, type, enum, etc. bug 140335
  • Inactive code highlighting. Highlight lines of code which are inactive (ie. which are excluded by conditional preprocessor directives) in the current scanner configuration. bug 81511

Content Assist

  • Convert to use the index whenver possible, and convert the DOM contributor to skip all headers. This should speed up content assist immensely. bug 169860
  • Code assist similar to java eclipse, in particular:
    • Show available method/fields completion list with Ctrl-Space,
    • Automatically add #include "file.h" when a function is added in code with Ctrl-Space
    • When a class method (or function) is deleted (with right mouse click), the declaration in header file should be automatically deleted.
    • When a method/function is added in c/cpp file, its declaration should be automatically added in its header file.
    • When a method/function's signature changes, it should also be updated in header file.
    • Show references of highlighted function/method

CView

  • Common Navigator extensions. Adopt the new Common Navigator (CN) framework and create CDT specific extensions to plug the content and functionality of the C/C++ Projects view (aka CView) into any Common Navigator view. The extensions will be initially contributed to the new general purpose "Project Explorer", which serves as a playground for early adopters of the technology (like JDT). This should also help to stabilize and improve the CN framework by providing feedback and bug reports. bug 140337

New Views

Build

CDT Build System

  • "New Project Model" Build System enhancements bug 115935
    • Standard and Managed Build System incorporation - current "Standard" and "Managed" build systems will be incorporated into one CDT Build System. This will allow to leverage the Standard Build system with the build configuration and tool-chain concepts, provide one common mechanism of tool-chain integration, build system configuration, maintainence, etc. bug 162728
    • Multi-language support - associating language ID with tools, per-InputType (language) include/macros settings calculation.
    • Tool-Chain Modifications - the functionality will allow changing tool-chain settings for the project. This includes: Tool-chain substitution, adding/removing/substituting tools in the tool-chain, builder substitution. bug 162729
    • Per-folder settings - allows specifying tool-chain settings (i.e. option values, tool-chain/tools to be used, includes/macros settings) on the folder level bug 109080, bug 83809

Managed Build

  • Complete the internal builder and make it the default, hopefully eliminating the need to write makefile generators - plan item.
  • Implement parallel builds with the internal builder - plan item.

Debugger

CDI

How to make the CDI model flexible and extensible Proposals. See also bug 162080.

Launching and Usability

Improve the launch experience with contextual launch commands and a launch configuration wizard. See also bug 154280.

Breakpoint Actions

Add support for extensible breakpoint actions that fire when breakpoints are hit. See also bug 118308.

Memory Space Support in Memory View

Expose the notion of memory spaces in the Memory view for CDI backends that want it. bug 114528.

Add-ons

Windows SDK C/C++ Support

Support the tool chain that comes with the Windows SDK for C/C++ development. This includes the Visual C++ compiler (cl), linker (link), library builder (lib) plan item as well as the debugger engine (dbgeng.dll) available with the Debugging Tools for Windows. plan item. This functionality will be provided in an optional feature.

MinGW SDK Support

Take advantage of the new project templates, internal builder, and prebuild indexes to build a MinGW bundle to simplify installs on Windows. This will be distributed via EasyEclipse.org and will include MinGW itself which is GPL. As well, support for the SDL (Simple DirectMedia Library, libsdl.org) as a plug-in SDK will also be provided (LGPL). These will serve as exemplary implementations for many 4.0 features. bug 171095

The original version of the 4.0 plan is here.

Documentation

User's Guide

The CDT user's guide hasn't been touched since CDT 3.0. It is out of date given then content in CDT 3.1. As well, it is probably in much need of a rewrite.

Programmer's Guide

As part of solidifying the APIs and extension points for the CDT, they will need to be documented. The Programmer's Guide needs to be updated to contain the javadoc and schema docs. As well, actual guide content should be provided to show how to use the APIs.

Corona

Release 1.0.0

The initial release of Corona is aligned with the Eclipse Europa release. Release dates are subject to change due to Europa project dependencies.

Milestone Date Comments
1.0.0.M5 Nov 20, 2006 ContextContainer / Distributed event model
1.0.0.M7 Jan 22, 2007 Server-side Eclipse / Web Services
1.0.0.M8 Feb 23, 2007 Europa M5 / EclipseCon demo
1.0.0.M9 Apr 6, 2007 Europa M6
1.0.0.RC0 May 18, 2007 Europa M7
1.0.0.GA Jun 29, 2007 Europa Release

Eclipse Monkey

The project did not provide any plan information.

Dynamic Language Toolkit (DLTK)

Last revised January 22, 2007

Please send comments about this draft plan to the dltk-dev@eclipse.org developer mailing list or eclipse.technology.dltk newsgroup.

Introduction

This document lays out the feature and API set for the second release of the Eclipse Dynamic Languages Toolkit Project, version 1.0.0.

Project components

DLTK project contains following components:

  • DLTK Core (set of extensible frameworks designed to build full featured dynamic language IDEs on top of which).
  • DLTK TCL (exemplary TCL IDE)
  • DLTK Python (exemplary Python IDE)
  • DLTK Ruby (exemplary Ruby IDE)

Release deliverables

Each DLTK component deliverables have the same form as is found in most Eclipse projects, namely:

  • Source code release, available as versions tagged "R1_0" in the project's CVS repository.
  • Software Development Kit (SDK) (includes runtime and tooling components, with sources, examples, and documentation) (downloadable and update site).
  • Component runtime binary distribution (downloadable and update site).
  • Component tests (downloadable and update site).

Release Milestones

Release milestone occurring at roughly 6 week intervals and follow the Platform milestone releases by approximately 1 week; that is, until the final 3.3 release of the Platform, upon which DLTK and other projects will release simultaneously. As DLTK is dependent upon the Platform only, DLTK will deliver its milestones within the following week. It is anticipated that DLTK will synchronize its release milestones with the Europa release schedule.

Target Operating Environments

DLTK 1.0 will support all operating environments supported by the Eclipse Platform itself. For a list of supported environments, refer to Eclipse Project 3.3 plan for a list of reference platforms.

Internationalization

The Eclipse Platform is designed as the basis for internationalized products. The user interface elements provided by the Eclipse SDK components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles. As a result, the Dynamic Languages Toolkit project will provide English strings in its default bundles and 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.

Features and Capabilities

A list of project requirements and agreed upon implementation timeframes is found in this document. For the milestones listed in this document, a set of overall themes 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.

Plan Items

Plan items reflect new features of the DLTK project, or areas where existing features will be significantly reworked. Plan items are indicated using keyword plan and have a state determined by 'Assigned To' and 'Target Milestone' fields in Bugzilla. Below is a list of possible states and what they mean:

  • Committed items - A committed bug is one that we have decided to address for the release.
  • Proposed items - A bug 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 items - 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.

Device Software Development Platform, Device Debugging

DSDP Device Debugging 0.9 Project Plan

Last revised 05 Feb 2007

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

This document lays out the technical features and project plan for the 0.9 (Europa) release of the Eclipse DSDP - Device Debugging Project.

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 and tasks for each of the project milestones.

Release deliverables

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

  • Source code release, available as versions tagged "R0_9" in the project's DD CVS Repository and DSF CVS Repository.
  • SDK (includes runtime, user and programmer documentation, with sources) (downloadable).
  • Runtime binary distribution (includes user documentation) (downloadable).
  • Examples (downloadable).
  • Unit tests (downloadable).

Release milestones

Release milestone will align and release with the Europa milestones starting with M4. The DD project is at the top of the technology stack (level 2):

  • Thursday January 4, 2007 - Milestone 4 (0.9 M4) - stable build
  • Friday February 23, 2007 - Milestone 5 (0.9 M5) - stable build
  • Friday April 6, 2007 - Milestone 6 (0.9 M6) - stable build (API freeze)
  • Friday May 18, 2007 - Milestone 7 (0.9 M7/RC0 - stable build
  • Friday June 29, 2007 - 0.9 Release on Europa train

Lock down and testing then begins with M7, and progress through a series of test-fix passes against candidates releases. When no critical bugs are found during testing, the release candidate is declared a release. DD 0.9 will be delivered as part of the Europa 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 Device Debugging project depends upon on the Eclipse Platform 3.3 and CDT 4.0. Additionally, DD 0.9 depends on language features in Java 5. For this release, the DD sources will be written and compiled against version 1.5.x of the Java Platform APIs (i.e., Java 2 Platform, Release 1.5.x SE).

Eclipse Platform SDK 3.3 will be tested and validated on a number of reference platforms (this list is updated over the course of the release cycle). The DD project wil be tested and validated against a subset of those listed for the platform.

Device Debugging 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 8
for Microsoft Windows
Red Hat Enterprise Linux WS 4 Intel x86 GTK Sun Java 2 Standard Edition 5.0 Update 8
for Linux x86

Eclipse and the DD code will 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

Device Debugging is designed as the basis for internationalized products. The user interface elements provided by DD components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles. Additional languages can be implemented by adopters of DD.

Compatibility and Dependencies

Compatibility of Release 0.9

DD 0.9 is the first public release of DD. DD will be developed in parallel with the Eclipse Platform SDK version 3.3. Each DD Milestone Release will be based on the most recent Platform Milestone available at the time of release. Therefore, DD 0.9 will be compatible with Eclipse Platform 3.3 release and will publish binary and source compatibilities with migration guides on subsequent releases.

API Contract

DD 0.9 is the first public release of DD. APIs published for the 0.9 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.

Though it is our goal to create stable APIs, being able to do so depends on the amount of API feedback we will get from the community. Given that DD 0.9 is the first release of DD, users should assume that all public APIs are povisional as described in eclipse quality. We do not guarantee 0.9 APIs will remain unchanged in the 1.0 release.

Features and Capabilities

Plan items listed bleow were defined according to contributor requirements and the DSDP and Eclipse Themes and Priorities (Preliminary Roadmap v3) set forth by the Eclipse Requirments Council.

Please use the DD Project plan items bugzilla query for an up-to-date list. See the corresponding bugzilla items for up-to-date status information on ongoing work and planned delivery milestones.

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.

Committed Items

Debugger Services Framework (DSF). The debugger services framework in an implementation of the new Eclipse debug adaptable interfaces.

Traditional Memory Render. A traditional memory rendering commonly found in embedded debugger applications will be released.

Proposed Items

GDB/mi Debugger Implementation. A standard GDB/mi protocol implementation will be provided for use with a Linux-based GDB debug engine.

Deferred Items

None at this time.

Device Software Development Platform, Target Management

DSDP - Target Management DRAFT 2.0 Plan

Last revised 11:00 CEST Jan 19, 2007

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 next feature release of the DSDP Target Management Project after RSE 1.0, designated TM release 2.0.

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. The plan is not entirely static: to ensure the planning process is transparent and open to the entire Eclipse community, we (the Target Management Project Lead) post plans in an embryonic form and revise them throughout the release cycle. 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 planning, or 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 plan items which are listed here for complete reference, but tracked individually through bugzilla. 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 Target Management Project provides data models, frameworks and tools for working with remote computer systems. The main deliverable is the Remote System Explorer (RSE), a feature-rich integrated perspective and toolkit for seamlessly working on remote systems. Besides that, we deliver flexible, re-usable components for Networking and Target Management that run stand-alone or integrated with RSE:

  • Target Management source code release, available as versions tagged "R2_0" in the project's RSE CVS Repository and TM Core CVS Repository .
  • Remote System Explorer (RSE):
    • RSE SDK (includes runtime, user and programmer documentation, with sources) (downloadable).
    • RSE client runtime binaries (split up by protocol, includes user documentation) (downloadable).
    • RSE dstore server runtime (downloadable).
    • RSE CDT Launch Integration (downloadable).
    • RSE tutorial code and examples (downloadable).
    • RSE unit test framework and tests (downloadable).
  • Stand-alone components:
    • TM Terminal SDK (includes runtime, user and programmer documentation, with sources) (downloadable).
    • TM Discovery SDK (includes runtime, user and programmer documentation, with sources) (downloadable).
    • Redistribution of Apache Jakarta Commons 1.4.1 and Apache ORO 2.0.8 (downloadable through the Orbit project).
Notes: The former experimental RSE EFS integration is scheduled to be moved into the standard RSE SDK and client runtime binaries, respectively. All stand-alone components will have an integration part that makes them work inside the RSE framework. For that reason, there are no downloadable stand-alone component tests, but the RSE unit test component will also have tests for the stand-alone components.

Release milestones

Release milestone will be occurring at roughly 6 week intervals, and will be aligned with the Europa Simultaneous Release train. Milestone names start with M4 in order to clarify this relationship. The milestones are:

  • Thursday January 4, 2007 - Milestone 4 (2.0 M4) - stable build
  • Friday February 23, 2007 - Milestone 5 (2.0 M5) - stable build
  • Friday April 6, 2007 - Milestone 6 (2.0 M6) - stable build (API Freeze)
  • Friday May 18, 2007 - Milestone 7 (2.0 M7/RC0) - stable build

Lock down and testing then begins with M7, and progress through a series of test-fix passes against candidates releases. As soon as no critical problems are found in the testing period between two release candidates (one or two weeks), a release candidate can be declared the release. The target date for availability of Target Management 2.0 is:

  • Friday June 29, 2007 - 2.0 Release target date

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 Target Management Project 2.0 depends upon on the Eclipse Platform 3.3. Various sub components also depend on other Eclipse Projects, namely the C/C++ Development Tools (CDT) 4.0 and the Eclipse Modeling Framework (EMF) 2.3. 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 Target Management will also be done on Java 5.

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

Target Management 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 8
for Microsoft Windows
Microsoft Windows XP Intel x86 Win32 IBM 32-bit SDK for Windows,
Java 2 Technology Edition 5.0
Microsoft Windows (tm-only) 2000 Intel x86 Win32 Sun Java 2 Standard Edition 1.4.2_13
for Microsoft Windows
Red Hat Enterprise Linux WS 4 Intel x86 GTK Sun Java 2 Standard Edition 5.0 Update 8
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
(tm-only) Ubuntu / Debian Linux 5.10 Intel x86 GTK Sun Java 2 Standard Edition 1.4.2_13
for Linux x86
Sun Solaris 10 SPARC GTK Sun Java 2 Standard Edition 5.0 Update 8
for Solaris SPARC
Sun Solaris 9 SPARC (tm-only) Motif Sun Java 2 Standard Edition 5.0 Update 8
for Solaris SPARC
Apple Mac OS X 10.4 Power Carbon Java 2 Platform Standard Edition (J2SE) 1.4.2
service release 2 for Tiger

Eclipse and Target Management 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 Target Management on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Target Management on a reference platform.

Although untested, Target Management 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 more details, see the Eclipse Project Plan Reference Platforms.

Datastore Agent Reference Platforms

The Datastore protocol is the default protocol shipped with RSE for accessing remote file systems, process info and shells. It requires a Datastore server (agent) running on the remote system. This Datastore agent is shipped as plain Java Source Code together with the RSE distribution. It should run fine on any Java Platform, with additional Data Miner Plug-ins that may be OS specific.

We will test and verify the Datastore agent on the following Reference Platforms, which are a subset of the Platforms we test the RSE UI on:

  • Red Hat Enterprise Linx 4, Intel x86, Sun 1.5.0_08 VM
  • SUSE Linux Enterprise Server 9, Intel x86, IBM 1.4.2 sr 3 VM
  • Apple Mac OS X 10.4, Power, Apple 1.4.2 sr 2 VM

Internationalization

The Remote System 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

Dependencies of Release 2.0

Target Management takes part in the Europa Simultaneous Release Train. Therefore, deliverables will be developed in parallel with

Each Target Management Milestone Release will be based on the most recent Milestone releases of underlying components available at the time of release as well as the final releases.

Compatibility of Release 2.0 with 1.0

In order to evolve APIs and especially foster more UI/Non-UI separation, Target Management 2.0 will not be compatible with RSE 1.0.

API Contract Compatibility: Target Management 2.0 will not be compatible with RSE 1.0.

Binary (plug-in) Compatibility: Target Management 2.0 will not be compatible with RSE 1.0.

Source Compatibility: Target Management 2.0 will not be compatible with RSE 1.0, but a Target Management 2.0 Migration Guide will be published that explains how to port RSE 1.0 applications to the TM 2.0 APIs. In most cases, "organize imports" should be sufficient in order to update API usage to classes refactored for better UI/Non-UI separation. Downward source compatibility is not supported.

Workspace Compatibility: We intend to keep Target Management 2.0 upwards workspace-compatible with RSE 1.0 unless noted. This means that workspaces and projects created with RSE 1.0 can be successfully opened by Target Mangement 2.0 and upgraded to a 2.0 workspace. This includes especially RSE 1.0 connection definitions, which may propagate between workspaces via file copying or team repositories. 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 TM 2.0 will be unusable with a product based on RSE 1.0.

API Contract

APIs published for the Target Management 2.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

Plan items listed bleow were defined according to contributor requirements, but in accordance with the Target Management Use Cases Document and the DSDP and Eclipse Themes and Priorities (Preliminary Roadmap v3) set forth by the Eclipse Requirments Council. Each plan item covers a feature or API that is to be added to the Target Management deliverables, or some aspect of the Target Management 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. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order. Use the TM Project plan items bugzilla query for an up-to-date list. See the corresponding bugzilla items for up-to-date status information on ongoing work and planned delivery milestones.

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.

Committed Items

Contribute User Actions and Import/Export from RSE7. The predecessor of Eclipse RSE was an IBM product, IBM RSE 7.0. Not all features of RSE 7.0 have been ported yet. For Eclipse RSE 2.0, we will port the missing features, namely User Actions, Compile Commands and Import/Export. While porting the features, they will be refactored and optimized, which may result in collapsing User Actions and Compile Commands into a single feature. See the link above for a presentation with more details about these features. (Themes: Ease of Use, Enterprise Ready / Facilitated On-Boarding) (170909)

Allow encoding of remote files to be specified. Provide UI components for specifying the encoding of remote resources for cases where it differs from the standard Platform encoding. This will allow to transparently edit such remote resources properly. Also, support transparent re-encoding of resources when doing copy&paste or drag&drop between folders that require different encodings. (Theme: Enterprise Ready) (163820)

Integrate the TM Terminal View with RSE. RSE provides a framework for registering data transfer protocols and managing connections. It provides a subsystem for executing commands on remote hosts through those protocols, but this is a line-oriented command view without terminal emulation. The current stand-alone TM Terminal View will be integrated with RSE as a new kind of subsystem that provides a terminal over any registered RSE IHostShell connection channel. (Theme: Ease Of Use) (170910)

Improve Discovery and Autodetect in RSE. Support the use cases defined by the Autodetect Group, namely finding remote systems such that they can be added as RSE connections; and finding services on those systems and registering them with RSE connections. A single RSE connection should be used for a single remote system detected, adding support for the services detected. (Theme: Ease Of Use) (170911)

Proposed Items

Adopt Eclipse Platform 3.3 concepts in RSE. TM should adopt Eclipse Platform concepts wherever possible. For instance, Move Commons Net packages into Orbit (needed for Europa); Improve drag&drop, copy&paste for Project Explorer, Package Explorer; Use Common Preferences for ssh and Proxy - Collaborate with Platform/Team on (170883); Adopt the Commands framework with retargetable actions (e.g. for Properties); Adopt ICU4J and Capabilities. (Theme: Persistent & Pervasive Themes; Ease of Use) (170915)

Fix and improve the RSE EFS integration. Given any files subsystem registered with RSE, RSE should be able to act as an EFS provider through that registered files subsystem. Current bugs with workspace resource locking should be fixed. In addition to that, it would be desirable to support an RSE subsystem under the Local system type that acts as an EFS browser, i.e. be able to access remote resources through any registered EFS provider. (Theme: Design for Extensibility) (170916)

Improve RSE SystemType and New Connection Wizard flexibility. ISVs need to be able to add new system types which are compatible with existing ones, and be able to automatically pick up subsystem implementations from 3rd parties that they don't know about initially. Additional states (and thus decorators) need to be considered by IHost objects and registered with systemTypes. More considerations need to be made for systemTypes that do not describe TCP/IP connections. Finally, contributors should be able to disable SystemTypes via capabilities and/or a dynamic enabler class. (Themes: Design for Extensibility, Embedded Device Software) (170918)

Optimize APIs - Remove obsolete API. RSE APIs should be made smaller (less API, more internal) in order to make them easier to understand and maintain. Eliminate dead code. Clarify threading model. Add asynchronous callbacks for long-runnint operations. (Theme: Design for Extensibility) (170922)

Improve UI/Non-UI splitting in RSE. Support headless launches. RSE code should be further refactored to split UI from non-UI parts. A Headless Eclipse should be able to perform Launches through RSE-provided services / subsystems. This means providing non-UI (headless) APIs for accessing the SystemRegistry, getting IHost objects; getting ISubSystem, ISubSystemConfiguration objects as well as services; and using IFileServiceSubsystem as well as other ISubSystem and IService APIs for actions like upload, download, run-shell-command during a headless Launch. (Theme: Design for Extensibility) (170923)

Improve the Remote File Service APIs. RSE File Service APIs should be sufficient to make a proper EFS provider. This means especially support for setting a file read-only / writable; changing a file's timestamp; preserving permissions when copying across systems; UI tools for reviewing / changing timestamp and read-only status; and returning potentially large remote files as streams for partial access, such that not the entire file is necessarily downloaded. In order to differenciate ourselves from EFS, we may add more tools that do not operate on an "abstract" file system but support more direct access to remote system's contributed permission and other status bits like Access Control Lists (ACLs). (Themes: Scaling Up, Design for Extensibility) (170926)

RSE should be more service-oriented. Currently, behavior of subsystems depends on the system type name they are registered against. Instead of this, Properties of system types should be used to modify subsystem behavior, such that existing subsystems can be added as services to more different system types. In addition to that, it should be possible to group services into a system; and support more dynamic enabling / disabling of subsystems / services based on availability. (Theme: Design for Extensibility) (150498)

Improve the RSE default Persistence Provider. For facilitated on-boarding, it should be easier to get access to pre-defined RSE connections out of a Team-Shared Repository or by importing/exporting connection definitions as XML. Fewer files should be used to store RSE state. It should be possible to associate connections, profiles, filter pools etc. with projects. Data storage should be flexible in the metadata or the project workspace, similar to the persistence mechanism used by Eclipse Launch Configurations today. (Theme: Enterprise Ready / Facilitated On-Boarding) (170932)

Add full support for Macintosh. MacOS X is a widespread Eclipse Platform and should be made official reference platform, thus giving bug reports a higher priority and doing automated unit testing regularly. (Theme: Platform Support) (170936)

Deferred Items

None at this time.

Data Tools Platform (DTP)

Document Status

  • [2/01/07]: Initial version reviewed and approved by the PMC.

Themes and Priorities

With the release of 1.0 in December, 2006, DTP graduated to mature status at Eclipse. As part of meeting the requirements to graduate, DTP built extender and user momentum. In DTP 1.5 we will seek to continue this trend by working on the following themes and priorities:

  • Work with extenders to validate further the DTP 1.0 provisional API set and make adjustments as necessary in an open, transparent, and community-driven manner.
  • If appropriate, promote select DTP 1.0 provisional API to platform status.
  • Enhance user tools to make DTP a compelling choice for developing data centric applications in Eclipse.
  • Accurately prioritize and address bugs, especially those having a severity of major or higher.
  • Grow the DTP community through direct contributions and external projects using DTP components.
  • Work with the WTP community to assist in the transition from WTP/rdb to DTP.
  • Make DTP easier to understand and leverage, from both the extender and user perspectives.
  • Meet milestone dates in tight synchronization with Europa plans.

Release Deliverables

The DTP 1.5 release will be distributed as follows:

  • A "end user" download, containing binaries for all DTP 1.5 components and end-user documentation
  • A "extender" (or "SDK") download, which adds extender documentation and source code to the "end user" distribution
  • An update site, containing feature definitions for component sets within DTP

The following feature definitions are planned for DTP 1.5:

  • Model base feature (org.eclipse.datatools.modelbase.feature)
  • Connectivity feature (org.eclipse.datatools.connectivity.feature)
  • Open Data Access (ODA) feature (org.eclipse.datatools.connectivity.oda.feature)
  • Open Data Access (ODA) designer feature (org.eclipse.datatools.connectivity.oda.designer.feature)
  • SQL Development Tools feature (org.eclipse.datatools.sqldevtools.feature)
  • Enablement feature (org.eclipse.datatools.enablement.feature)
  • Enablement Open Data Access (ODA)feature (org.eclipse.datatools.enablement.oda.feature)
  • Enablement Open Data Access (ODA)designer feature (org.eclipse.datatools.enablement.oda.designer.feature)
  • User documentation for Connectivity feature (org.eclipse.datatools.connectivity.doc.user)
  • User documentation for SQL Development Tools feature (org.eclipse.datatools.sqldevtools.doc.user)
  • Welcome Page content feature (org.eclipse.datatools.intro)
  • Extender ("SDK") feature (org.eclipse.datatools.sdk)

Additional features, or changes to the features above might occur based on evolving requirements. This document will be updated to reflect the current planned feature definitions for DTP 1.5 going forward.

Release Milestones

DTP 1.5 is part of the Europa release. As such, our milestones, release candidates, and final release date are determined by Europa. DTP is a "+1 dependency" on the Eclipse platform, and the dates of specific milestones can be found here, Milestones and Release Candidates section.

Europa, like Callisto, is designed to shrink the lag time between platform milestones and downstream projects as the release approaches. Thus, while DTP is a "+1" dependency at the current time, DTP builds for later platform releases (typically in the release candidate periods) will appear in less than one week from the platform milestone. The DTP PMC interprets the downstream lag as an idealized upper limit, and will seek to make matching DTP builds available as soon as possible after platform milestones, typically with a 24 hour (business day) delay for testing. Hence, if a platform milestone appears on a Friday, DTP will seek to have its corresponding build by the end of the following Monday. Such builds will be designated as Integration builds and subject to further testing past that date. The general disclaimer is that DTP can not guarantee hitting these dates due to bugs that might appear in integration tests and availability of additional dependencies other than the platform (for example, EMF and GEF).

Target Operating Environments

The build, test, and deployment environments for DTP 1.5 are described here.

Individual Project Plans

  • Model Base: (Add link here)
  • Connectivity: Connectivity Plan for Europa
  • SQL Development Tools: (Add link here)
  • Enablement: In DTP 1.5, we are planning a number of additions to Enablement. These include:

Work Items

This Bugzilla query shows all items currently planned for DTP 1.5.

Eclipse Communications Framework (ECF)

ECF Project Milestone Plan

Last modified on Feb 5, 2007 by slewis

See here for Javadocs of ECF APIs

See Wiki for Sub-Project Info, Conference Call Schedule, and Longer-Range Planning

0.9.4

Target Release Date: 12/02/2006
Actual Release Date: 12/03/2006
Download
New and Noteworthy

Features Committer/Contributor Enhancement Request/Bug
Document new org.eclipse.ecf.ui.configurationWizards and org.eclipse.ecf.ui.connectWizards extension points Scott Lewis See New and Noteworthy for 0.9.4

0.9.5

Target Release Date: 12/15/2006
Actual Release Date: 12/22/2006
Download
New and Noteworthy

Features Committer/Contributor Enhancement Request/Bug
Refactor test code and move into org.eclipse.ecf.tests plugin Scott Lewis #161497
Refactor RosterView to allow easier extension Scott Lewis #166675
Update IRCLib to v1.10 Scott Lewis #166418
Refactor presence API in org.eclipse.ecf.presence bundle Scott Lewis #167363
[provider] filetransfer provider based upon httpclient 3.0.1 Scott Lewis #166079

0.9.6

Target Release Date: 1/12/2007
Actual Release Date: 1/13/2007
Download
New and Noteworthy
Features Committer/Contributor Enhancement Request/Bug
Add persistence to RosterView Scott Lewis #166670
[provider] BitTorrent provider for file transfer (receive) API Remy Suen and Scott Lewis #144133
[IRC] Able to open links in internal browser Remy Suen #148874
Create New Connect Wizard for XMPP Client Scott Lewis #165508
Create New Connect Wizard for IRC Client Remy Suen #165511

1.0.0.M5

Target Release Date: 2/16/2007
Features Committer/Contributor Enhancement Request/Bug
Documentation about running the test suite Unassigned #126505
Integration of ECF Roster with Mylar 1.0 Unassigned #111218
#106562
Additional UI features for IM and multi-user chat Unassigned #110896
Refactor test code for presence and datashare APIs and move into org.eclipse.ecf.tests plugin Scott Lewis #161497
Move org.eclipse.ecf.provider.rss from Higgins' repository to ECF's Scott Lewis #166016
Complete bulletin board API, get IP approval for contribution, and integrate in with ECF on dev.eclipse.org Erkki Lindpere and Scott Lewis #150756
Create New Connect Wizard for JXTA Client Pierre Henry-Perret #165514

Eclipse Modeling Framework (EMF)

The project did not provide any plan information.

EMF Technology (EMFT)(OCL, Query, Transaction, Validation, JET)

The project did not provide any plan information.

Graphical Editor Framework (GEF)

Last revised : 2006/11/01 20:26:18 $ ( marks interesting changes over a previous revision of this document)

    Please send comments about this draft plan to the eclipse.tools.gef newsgroup.

This document lays out the feature and API set for the next feature release of the Graphical Editing Framework (GEF) project, designated release 3.3.0.

Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, 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 GEF project. Each plan item covers a feature that is to be added, or some aspect that is to be improved. Each plan item will have 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 subsystem; others may involve coordinated changes across several projects within the same top-level project; and others may involve coordination with other top-level projects. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.

With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance 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 release deliverables are:

  • Source code release for GEF is available in the eclipse.org CVS repositories for GEF.
  • GEF runtime binaries and SDK distributions (downloadable).
  • GEF runtime binaries and SDK features on eclipse.org update site (install via Eclipse update manager).

Release Milestones

GEF builds are available weekly as Integration builds. GEF Milestone Releases are approximately one week after the Eclipse Milestone Releases .

Following the final milestone, release candidates will begin. GEF Release Candidates are planned to be released approximately one week after each Eclipse Release Candidate. This convergence is required to meet the goals of the Europa Simultaneous Release.

Scheduled release candidates should end in 2007Q2, and beyond that point, will be produced only as needed, leading up to a release in late 2007Q2.

Target Operating Environments

GEF 3.3 will support all operating environments supported by the Eclipse Platform itself. For a list of supported environments, refer to Eclipse Project 3.3 plan for a list of reference platforms.

Compatibility with Previous Releases

Compatibility of Release 3.3.0 with 3.2.0

GEF 3.3 will be upwards compatible with GEF 3.2 to the greatest extent possible. Any exceptions will be noted in the 3.3 release notes so that clients can assess the impact of these changes on their plug-ins and products.

API Contract Compatibility: GEF 3.3 will be upwards contract-compatible with GEF 3.2 unless noted. This means that programs in full compliance with contracts specified in 3.2 APIs will automatically be in full compliance with 3.3 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: GEF 3.3 will be upwards binary-compatible with GEF 3.2 unless noted. This means that plug-ins built for GEF 3.3 will continue to work correctly in 3.3 without change. Plug-ins with hard-coded references in their plug-in manifest file to the 3.2 version of GEF plug-ins will work in 3.3 provided the version match rule is "greaterOrEqual" or "compatible" (the default); references using "perfect" or "equivalent" match rules will be broken. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: GEF 3.3 will be upwards source-compatible with GEF 3.2 to the greatest extent possible. This means that source files written to use 3.2 APIs can often be successfully compiled and run against GEF 3.3 APIs. Since source incompatibilities are easy to deal with, maintaining source compatibility is considered much less important than maintaining contract and binary compatibility.  The addition of a single method anywhere could be an incompatible source change.  For this reason, source-incompatibilities will not be noted.

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 as 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 changes under consideration for the next release of Eclipse GEF address a few major themes:

  • Revisit Performance - GEF has always been a framework for delivering integrated tools. With a growing base of both free and commercial offerings based on GEF, it's critical for continued success to ensure that the framework scales well. This theme is to measure and improve the performance and scalability of GEF.
  • Usability Enhancements - There are various issues raised on the usability of GEF based diagrams. This theme is to improve usability of applications based on GEF.
  • Defect Cleanup - There are around 200 open Bugzillas, this theme works torward reducing this backlog.
  • GEF diagram layer test automation - TPTP includes a SWT test automation framework which currently does not include diagram (GEF) support. This theme is to look at providing integration with GEF for diagram layer testing. There is an enhancement request (Bug 133099) for this and it has been frequently requested by the community.

The current status of each plan item is noted:

  • Plan Item items - a Plan Item that we have decided to address for the release. To see all committed items - see "committed" items
  • Committed items - A committed bug is one that we have decided to address for the release.
  • Proposed items - A bug 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 items - 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.

Graphical Modeling Framework (GMF)

Introduction

This document lays out the feature and API set for the second release of the Eclipse Graphical Modeling Framework Project, version 2.0.0.

This project plan inherits from the Modeling Project Plan, which should be referenced when consulting this individual project plan.

Release deliverables

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

  • Graphical Modeling Framework source code release, available as versions tagged "R2_0" in the project's CVS repository.
  • Graphical Modeling Framework SDK (includes runtime and tooling components, with sources, examples, and documentation) (downloadable and update site).
  • Graphical Modeling Framework runtime binary distribution (downloadable and update site).
  • Graphical Modeling Framework tests (downloadable and update site).

Release milestones

Release milestone occurring at roughly 6 week intervals and follow the Platform milestone releases by approximately 2 weeks; that is, until the final 3.3 release of the Platform, upon which GMF and other projects will release simultaneously. As GMF is dependent upon the EMF, GEF, and other projects, which are scheduled to release milestones within 1 week of Platform milestones, GMF will deliver its milestones within the following week. It is anticipated that GMF will synchronize its release milestones with the Europa release schedule. The milestones are:

  • Monday September 04, 2006 - Milestone 1 (2.0 M1) - stable build, tagged M1_20 in CVS
  • Friday October 13, 2006 - Milestone 2 (2.0 M2) - stable build, tagged M2_20 in CVS
  • Friday November 17, 2006 - Milestone 3 (2.0 M3) - stable build, tagged M3_20 in CVS
  • Friday January 04, 2007 - Milestone 4 (2.0 M4) - stable build, tagged M4_20 in CVS
  • Friday February 23, 2007 - Milestone 5 (2.0 M5) - stable build, tagged M5_20 in CVS
  • Friday April 06, 2007 - Milestone 6 (2.0 M6) - stable build, tagged M6_20 in CVS (API freeze)
  • Friday May 18, 2007 - Milestone 7 (2.0 M6/RC0) - stable build, tagged M7_20 in CVS

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

  • Friday June 01, 2007 - Release Candidate 1 - (2.0 RC1)
  • Friday June 15, 2007 - Release Candidate 2 - (2.0 RC2)
  • Friday June 29, 2007 - Release - (2.0)

As these milestones are dependent upon the Platform, they may be altered in order to conform to the published plan. 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.

Maintenance Stream

GMF 1.0.1 and 1.0.3 maintenance releases will align with the Callisto release that includes the Eclipse Platform 3.2.1 and 3.2.2 releases, respectively.

  • Friday, September 29, 2006 - GMF 1.0.1 maintenance release
  • Friday, October 27, 2006 - GMF 1.0.2 maintenance release
  • Friday, February 9, 2007 - GMF 1.0.3 maintenance release

A list of issues indicated for the 1.0.x maintenance stream can be found here: 1.0.1,1.0.2 and 1.0.3.

Target Operating Environments

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

The Eclipse Graphical Modeling Framework (GMF) project depends upon on the Platform and other projects, which are mostly "pure" Java. The 3.3 release of the Eclipse Platform Project is written and compiled against version 1.4 of the Java Platform APIs, and targeted to run on version 1.4 of the Java Runtime Environment, Standard Edition. The Eclipse Modeling Framework (EMF) project has declared to support Java 5 language features in its next release (3.3.0), and will therefore require a Java 5 runtime environment. GMF will target the same Java version as EMF.

Eclipse Platform SDK 3.3 will be tested and validated on a number of reference platforms. GMF will be tested and validated against a subset of those listed for the platform. Those available will be presented on the project download site.

Internationalization

The Eclipse Platform is designed as the basis for internationalized products. The user interface elements provided by the Eclipse SDK components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles. As a result, the Graphical Modeling Framework project will provide English strings in its default bundles and 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 2.0

The Graphical Modeling Framework Project will be developed in parallel, and released simultaneously, with the following projects. As stated above, each milestone release of the Graphical Modeling Framework Project will be compatible with the corresponding milestones for each of these projects, and delivered the appropriate offset.

  • Eclipse Platform SDK version 3.3
  • Eclipse Modeling Framework (EMF) version 3.0
  • Graphical Editing Framework (GEF) version 3.3

Therefore, the Graphical Modeling Framework initial release will be compatible with these versions and will publish binary and source compatibilities with migration guides on subsequent releases.

API Contract

It is a goal of the Graphical Modeling Framework Project to avoid provisional APIs. APIs published for the 2.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. Note that GMF follows the posted Version Numbering guidelines.

Compatibility of Release 2.0.0 with 1.0.0

GMF 2.0.0 will be compatible with GMF 1.0.0, except in those areas noted in the GMF 2.0.0 Migration Guide. API contract, binary compatibility, etc. follow those described in the Modeling Project Plan.

GMF 2.0.0 Migration Guide

At this time, there are no known issues migrating from 1.0.0 to 2.0.0. Should this change, this document will be revised, or a secondary document will be added documenting any known issues.

Features and Capabilities

A list of project requirements and agreed upon implementation timeframes is found in this document. For the milestones listed in this document, a set of overall themes 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.

2.0 Themes

Taking into consideration the themes provided by the Requirements Council, overall Modeling project themes and the GMF 1.0 release state and community feedback, the following themes are planned to be addressed in the 2.0 release:

API

A number of items related to the GMF API are planned to be addressed, including the addition of new APIs, refactoring of old APIs, and improved API documentation. A list of those plan items related to API (keyword=api) can be found here.

Usability

A number of usability items related to runtime and tooling components of GMF are found in this section. A list of those plan items related to Usability (keyword=usability) can be found here.

Model[ing] Citizen

As a project within the Eclipse Modeling Project, a number of build dependency and interoperability items exist with other Modeling projects. A number of releng tasks and support of GMF's use in providing UML2 diagramming are anticipated to be addressed in the 2.0 release timeframe. Furthermore, as GMF 2.0 is scheduled to release with the Europa simultaneous release, along with other Modeling projects, some coordination and requirements for being on the release train is also anticipated.

Performance

A number of performance issues have been identified and will be worked during the 2.0 timeframe. A list of those plan items related to Performance (keyword=performance) can be found here.

Plan Items

Plan items reflect new features of the GMF project, or areas where existing features will be significantly reworked. Plan items are indicated using keywords and have a state determined by 'Assigned To' and 'Target Milestone' fields in Bugzilla. Below is a list of possible states and what they mean:

  • Committed items - A committed bug is one that we have decided to address for the release.
  • Proposed items - A bug 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 items - 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.

Plan Item Queries

Plan Items

All Open | All Resolved | All Items

2.0 M1 | 2.0 M2 | 2.0 M3 | 2.0 M4 | 2.0 M5 | 2.0 M6

Committed Items

Bugzillas with a target milestone and developer assigned are considered committed in that release. For the most current list of these items for the 2.0.0 release, see the following links:

All Open | All Resolved | All Items

Proposed Items

Bugzillas without an assigned developer are proposed, but not committed for a particular release. For the most current list of these items, see the following links:

Open | Resolved

Deferred Items

Bugzillas with an unspecified target milestone are deferred, and not scheduled for the current release. For the most current list of these items, see the following link:

All Open

Help Wanted Items

Bugzillas with a 'helpwanted' keyword are in need of contribution from the community. For the most current list of these items, see the following link:

All Open

Modeling Development Tools

Eclipse MDT
DRAFT 1.0 Plan

Last revised 20:28 EST December 19, 2006 ( marks interesting changes over the previous plan revision)

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

This document lays out the feature and API set for the next feature release of the Eclipse MDT project, designated release 1.0.

Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, 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 components under the Eclipse MDT 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.

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 subsystem; others may involve coordinated changes across several projects within the same top-level project; and others may involve coordination with other top-level projects. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.

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 into 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 are:

  • Source code release for the EODM component, available as versions tagged "R2_0" in the eclipse.org CVS repository.
  • EODM runtime binary and SDK distributions (downloadable).
  • EODM runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for the OCL component, available as versions tagged "R1_1" in the eclipse.org CVS repository.
  • OCL runtime binary and SDK distributions (downloadable).
  • OCL runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for the UML2 component, available as versions tagged "R2_1" in the eclipse.org CVS repository.
  • UML2 runtime binary and SDK distributions (downloadable).
  • UML2 runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for the UML2 Tools component, available as versions tagged "R1_0" in the eclipse.org CVS repository.
  • UML2 Tools runtime binary and SDK distributions (downloadable).
  • UML2 Tools runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for XSD component, available as versions tagged "R2_3" in the eclipse.org CVS repository.
  • XSD runtime binary and SDK distributions (downloadable).
  • XSD runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).

Release milestones

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

  • Thursday, November 16 – Milestone 3 (1.0 M3) – Stable Build based on Eclipse 3.3 M3
  • Thursday, January 4 – Milestone 4 (1.0 M4) – Stable Build based on Eclipse 3.3 M4
  • Friday, February 23 – Milestone 5 (1.0 M5) – Stable Build based on Eclipse 3.3 M5
  • Friday, April 6 – Milestone 6 (1.0 M6) – API Freeze – Stable Build based on Eclipse 3.3 M6
  • Friday, May 18 – Milestone 7 (1.0 RC0) – Stable Build based on Eclipse 3.3 RC0

The 1.0 release is targeted for late June 2007. 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 release of an Eclipse project targets reasonably current versions of underlying operating environments and other Eclipse projects on which it depends. 

Most of Eclipse is "pure" JavaTM code and has no direct dependence on the underlying operating system. The chief dependence is on the Eclipse Platform, and on the Java 2 Platform that runs it.

The MDT 1.0 release depends on the following:

  • Java 2 Platform 1.5
  • Eclipse Platform 3.3
  • EMF 2.3
  • GMF 2.0

The 1.0 release of MDT is designed to run on any configuration supporting the above components.

The Eclipse Platform runs 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 undoubtedly runs fine in many operating environments beyond the reference platforms we test. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Eclipse on non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse on a reference platform.

See the Eclipse Project 3.3 plan for a list of 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 MDT are provided as the default resource bundles. Translations are not provided with this release. However, the plug-in fragment mechanism provides the means by which translations into any number of other languages can be incorporated.

Compatibility with Previous Releases

Compatibility of EODM 2.0 with 1.0

The EODM 2.0 component of Eclipse MDT will not be compatible with EODM 1.0.

API Contract Compatibility: EODM 2.0 will not be upwards contract-compatible with EODM 1.0 as noted in the EODM 2.0 Migration Guide. Programs that use affected APIs and extension points will need to be ported to EODM 2.0 APIs. Downward contract compatibility is not supported. Compliance with EODM 2.0 APIs would not ensure compliance with EODM 1.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: EODM 2.0 will not be upwards binary-compatible with EODM 1.0 as noted in the EODM 2.0 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against EODM 2.0 will be unusable with EODM 1.0. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use EODM 1.0 APIs will not compile and run successfully against EODM 2.0 APIs. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: EODM 2.0 will not be upwards workspace-compatible with EODM 1.0 as noted. This means that workspaces and projects created by an Eclipse with EODM 1.0 installed cannot be successfully opened by an Eclipse with EODM 2.0 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

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

Compatibility of OCL 1.1 with 1.0

The OCL 1.1 component of Eclipse MDT will be compatible with OCL 1.0, except in those areas noted in the OCL 1.1 Migration Guide.

API Contract Compatibility: OCL 1.1 will be upwards contract-compatible with OCL 1.0 except in those areas noted in the OCL 1.1 Migration Guide. Programs that use affected APIs and extension points will need to be ported to OCL 1.1 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with OCL 1.1 APIs would ensure compliance with OCL 1.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: OCL 1.1 will be upwards binary-compatible with OCL 1.0 except in those areas noted in the OCL 1.1 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against OCL 1.1 will likely be unusable with OCL 1.0. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use OCL 1.0 APIs will usually compile and run successfully against OCL 1.1 APIs, although this cannot be guaranteed. Because OCL 1.1 may exploit new Java language constructs and/or aspects of the OCL specification, there is an increased chance of source incompatibilities compared to previous OCL releases. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: OCL 1.1 will be upwards workspace-compatible with OCL 1.0 unless noted. This means that workspaces and projects created by an Eclipse with OCL 1.0 installed can be successfully opened by an Eclipse with OCL 1.1 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

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

Compatibility of UML2 2.1 with 2.0

The UML2 2.1 component of Eclipse MDT will be compatible with UML2 2.0, except in those areas noted in the UML2 2.1 Migration Guide.

API Contract Compatibility: UML2 2.1 will be upwards contract-compatible with UML2 2.0 except in those areas noted in the UML2 2.1 Migration Guide. Programs that use affected APIs and extension points will need to be ported to UML2 2.1 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with UML2 2.1 APIs would ensure compliance with UML2 2.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: UML2 2.1 will be upwards binary-compatible with UML2 2.0 except in those areas noted in the UML2 2.1 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against UML2 2.1 will likely be unusable with UML2 2.0. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use UML2 2.0 APIs will usually compile and run successfully against UML2 2.1 APIs, although this cannot be guaranteed. Because UML2 2.1 may exploit new Java language constructs, there is an increased chance of source incompatibilities compared to previous UML2 releases. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: UML2 2.1 will be upwards workspace-compatible with UML2 2.0 unless noted. This means that workspaces and projects created by an Eclipse with UML2 2.0 installed can be successfully opened by an Eclipse with UML2 2.1 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

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

Compatibility of XSD 2.3 with 2.2

The XSD 2.3 component of Eclipse MDT will be compatible with XSD 2.2, except in those areas noted in the XSD 2.3 Migration Guide.

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

Binary (plug-in) Compatibility: XSD 2.3 will be upwards binary-compatible with XSD 2.3 except in those areas noted in the XSD 2.3 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against XSD 2.3 will likely be unusable with XSD 2.2. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use XSD 2.2 APIs will usually compile and run successfully against XSD 2.3 APIs, although this cannot be guaranteed. Because XSD 2.3 may exploit new Java language constructs, there is an increased chance of source incompatibilities compared to previous XSD releases. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: XSD 2.3 will be upwards workspace-compatible with XSD 2.2 unless noted. This means that workspaces and projects created by an Eclipse with XSD 2.2 installed can be successfully opened by an Eclipse with XSD 2.3 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

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 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 changes under consideration for the next release of Eclipse MDT align with themes identified by the Eclipse Requirements Council and Modeling project.

EODM component

EODM is an implementation of RDF(S)/OWL metamodels of the Ontology Definition Metamodel (ODM) using EMF with additional parsing, inference, model transformation and editing functions. Plan items reflect new features of the EODM component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items (EODM component)

Standard Compliance. Provide a new API that is compliant with the (to be adopted) 5th submission of the ODM specification to the OMG. (162682) [Theme: Appealing to a Broader Community]

Dynamic Typing. Provide support for dynamic typing. (162683) [Theme: Appealing to a Broader Community]

RDF/OWL Parsing and Serialization. Provide support for RDF/OWL parsing and serialization. (162684) [Theme: Appealing to a Broader Community]

RDF/OWL Reasoning. Provide support for RDF/OWL reasoning. (162685) [Theme: Appealing to a Broader Community]

RDF/OWL Transformation to/from Ecore. Provide a mechanism to transform RDF/OWL models to/from Ecore. (162686) [Theme: Cohesion]

Proposed Items (EODM component)

None at this time.

Deferred Items (EODM component)

None at this time.

OCL component

OCL is an implementation of the OCL OMG standard for EMF-based models. Plan items reflect new features of the OCL component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items ( OCL component)

Parsing API. Provide a public API for parsing OCL documents, with the complete context declaration syntax. (144210) [Theme: Design for Extensibility – Be a Better Platform]

Integration with UML. Provide support for parsing and evaluating OCL constraints and expressions on the UML metamodel. (105199) [Theme: Cohesion]

EMF 2.3 / J2SE 5 Support. Adopt EMF 2.3, including regeneration of the OCL metamodel. (156361) [Theme: Design for Extensibility – Be a Better Platform]

Improved Documentation. Develop a complete Programmer’s Guide for the OCL subcomponent. (156360) [Theme: Simple to Use]

LPG. Consume LPG runtime library from the Orbit project. (156366) [Theme: Project Restructuring]

Stand-alone support. Provide a stand-alone (Eclipse-free) OCL build. (136817) [Theme: Appealing to a Broader Community]

ICU4J. Isolate and minimize dependency on ICU4J; ensure support for the “thin” variant of ICU4J. (156364) [Theme: Enable Consistent Multi-language Support]

Proposed Items ( OCL component)

Standard Compliance. Maintain currency of the API with the OMG’s OCL, ensuring backward API compatibility as much as possible. (156363) [Theme: Appealing to a Broader Community]

OCL Conformance. Validate and document the API’s conformance to the OCL Specification’s compliance points. This includes which language capabilities are supported and which metamodels (EMOF/Ecore, UML) are supported. (152003) [Theme: Design for Extensibility – Be a Better Platform]

Deferred Items ( OCL component)

None at this time.

UML2 component

UML2 is an EMF-based implementation of the UMLTM 2.x metamodel for the Eclipse platform. Plan items reflect new features of the UML2 component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items (UML2 component)

Eclipse 3.3 / EMF 2.3 Compatibility. Maintain release currency concurrent with EMF 2.3 (and Eclipse 3.3). Make changes as required to align with EMF features and bug fixes, in particular support for Java SE 5.0. (160679) [Theme: Cohesion]

Improved Documentation. Improve documentation by updating the FAQ, enhancing the Javadoc, and publishing new articles. (77413) [Theme: Simple to Use]

Ant Task for Ecore Importer. Provide an Ant task for the UML Ecore importer, similar to those provided for the Rose and Ecore importers in EMF. (160680) [Theme: Design for Extensibility – Be a Better Platform]

Static Profile Definition. Provide a way to specify that a profile definition be generated using EMF. This would allow, among other things, support for custom data types and derived stereotype properties. (155535) [Theme: Appealing to a Broader Community]

XML Primitive Types. Provide a model library to represent the types defined in the XMLType metamodel in EMF; be sure to update Ecore/UML converters to make use of this new library. (150154) [Theme: Cohesion]

BiDi Support. Provide better support for BiDi languages. (160682) [Theme: Enable Consistent Multi-language Support]

Create Child/Sibling Menu Reorganization. Reorganize the ‘Create Child’ and ‘Create Sibling’ menus of the UML editor so that the items are grouped by feature. (160684) [Theme: Simple to Use]

Integration with OCL. Integrate support for parsing and evaluating OCL constraints and expressions. Consider providing a convenience method on Constraint for returning the parsed representation of OCL expressions. (105199) [Theme: Cohesion]

Proposed Items (UML2 component)

Unit Tests. Complete the implementation of generated unit tests. (80308) [Theme: Design for Extensibility – Be a Better Platform]

Validation Rules. Complete the generation and implementation of validation rules from the UMLTM 2.1 source model. (80307) [Theme: Appealing to a Broader Community]

Deferred Items (UML2 component)

None at this time.

UML2 Tools component

UML2 Tools is set of GMF-based editors for viewing and editing UML models. Plan items reflect new features of the UML2 Tools component ( marks completed work).

Committed Items (UML2 Tools component)

Class Diagrams. Provide a GMF-based editor for UML class diagrams. (80318) [Theme: Appealing to a Broader Community]

State Machine Diagrams. Provide a GMF-based editor for UML state machine diagrams. (161572) [Theme: Appealing to a Broader Community]

Component Diagrams. Provide a GMF-based editor for UML component diagrams. (161573) [Theme: Appealing to a Broader Community]

Activity Diagrams. Provide a GMF-based editor for UML activity diagrams. (161574) [Theme: Appealing to a Broader Community]

Proposed Items (UML2 Tools component)

Import/Export from/to DI. Provide a mechanism whereby UML diagrams can be imported/exported from/to a format based on the Diagram Interchange specification. (161575) [Theme: Appealing to a Broader Community]

Deferred Items (UML2 Tools component)

None at this time.

XSD component

XSD is a library that provides an API for manipulating the components of an XML Schema as described by the W3C XML Schema specifications, as well as an API for manipulating the DOM-accessible representation of XML. Plan items reflect new features of the XSD component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items (XSD component)

Java SE 5.0 Support. Exploit new Java language constructs; use generics (e.g. EList, EMap and implementations); generate and merge Java 5 constructs; investigate enumerations and annotations. (79768) [Theme: Appealing to a Broader Community]

XSD2Ecore Enhancements. Improve ability to record complex content models as Ecore annotations. (152373) [Theme: Cohesion]

Proposed Items (XSD component)

None at this time.

Deferred Items (XSD component)

None at this time.

 

Mylar

Milestones

Mylar milestones are released 1 week after Eclipse milestones. Click to view open bugs.

Scope

The first goal of Mylar is to make task and context management seamlessly integrated with the Eclipse Platform by providing rich and extensible frameworks for task repository connectors, structure bridges and team support. The second goal is to provide a reference implementation of the Task-Focused UI for the Eclipse SDK. This includes structure bridges for the artifacts supported by the SDK which include Java, PDE, Ant and generic files. It also includes the Bugzilla Connector as the reference task repository implementation, and CVS integration as the reference team support. Additional features can be considered based on the availability community contributions and resources.

Priorities

In addition to using the planned themes listed below, we need to continue prioritizing the ongoing input of our growing user community. Committers should prioritize bugs in the following order. This order need not be used if a bug contains a community contribution of a patch, in which case the quality of the patch determines the priority.

  1. Frameworks & APIs: Tasks Framework, Context Framework, Monitor Framework, headless use
  2. UI: Tasks List, Task Editor, Task-focused UI
  3. Connectors: Bugzilla (reference implementation), Trac (committer supported), JIRA (community supported)

Platforms

  • Eclipse 3.3: supported
  • Eclipse 3.2: supported, post 2.0 maintenance builds only
  • Requires Java 5 and later

Themes

Legend: in progress, completed, optional

Task List

  • Support date view in Task List. A common way of organizing tasks to work on in the current week is by day. We should support this by integrating the Task Activity view's date range container presentation with the Task List. (147084)
  • Support integration with planning and calendaring tools. Many task repositories have facilities for task planning in the form of milestones, due dates, and other organizations of tasks. The Task List and Task Editor should support such extensions, for example, allowing the Task List to be organized by milestone. (Calendaring, privacy controls) (e.g. 152490).
  • Support task dependencies. Many tasks are related to other tasks, whether it's because they should be worked on in sequence or are subtasks. We should make these dependencies explicit in the Task List and Task Editor. (137543)
  • Support working set groupings. A Task List that includes projects from multiple "working spheres" (e.g. Project A, Project B, Personal) can become unwieldy and distracting. Integration of top-level working sets could address this.

Task Editing

  • Increase Task Editor information density. The task editor is a very frequent target of interaction, and we need to continue streamlining it. When opened it should show the user the most relevant information with minimal clicking and scrolling required. (158921).
  • Improve task activity timing. We currently have a task activity mechanism, but it is not explicit enough, and does not capture time spent outside of the workbench. It should also be extensible to OS-specific monitoring. (135668).
  • Provide task workflow mechanism. There are many common workflows, such as commit/complete/deactivate. We should provide a mechanism for specifying and executing task-related workflows. This requires direct editing of task data (i.e., without editor submission). (160780, 124224)
  • Streamline task creation. Make it easier to create tasks, fork them, or promote local tasks to repository tasks. (154896, 152211)

Task Repositories

  • Make offline cache faster and more robust. The offline cache is currently one large serialized file. We should make it more robust so that changes to connectors and the framework do not cause the offline data to be cleared. This should make it possible to put a repository into offline mode permanently, and never lose the task data. (165809)
  • Streamline task searching. It is currently impossible to search through local and cached task data. We could improve the search experience by providing Google-style syntax in the Task List find box, e.g. severity=critical. (bug 163341)
  • Improve connectivity problem and performance handling. Lack of or degraded connectivity should be transparent, and jobs should be cancellable. (165833)
  • Improve synchronization control. (offline mode for repositories bug 165809, finer-grained control bug 165473)
  • Provide standard XML for for tasks. We should create a canonical and extensible XML for for tasks that we use for retrieving task data. Connector providers returning this form would not need custom attribute mappings.
  • Improve consistency between local and repository tasks. Need to consider how to promote task between local and repository, and whether local tasks should be a kind of repository. (12431)

Task-Focused UI

  • Provide preview and editing of task context. For submitting and retrieving contexts, or wanting to inspect a context for a non-active task, we should provide a preview pane. This should also support operations such as merge and element deletion. (bug 107259)
  • Support debugging views. This includes improved filtering of the thread tree, and automatic toggling/loading of breakpoints with task context.
  • Preserve element identity through refactoring. Currently only the active context participates in refactoring. We either need to maintain a dependency map to update the element handles of inactive contexts, or migrate them when they are activated, via the refactoring history. (164243)

General

  • Improve error handling and resolution. When an error happens, we should do automatic duplicate detection, and if no duplicate is found prompt to submit a bug to the failing plug-in.
  • Generalize task and context storage mechanisms. Our API currently specifies files and paths as the storage mechanism, but it should be general, to allow for alternate mechanisms such as server-based storage.
  • Improve representation of people. Support real names, selecting CCs, content assist for fields with people. The user's identity should be represented in the UI (e.g. different icon when user appears in the CC list).
  • Hyperlinking everywhere. Wherever structured elements show up, we should be hyperlinking them (e.g. bug 165827)
  • Personal monitoring and usage sharing. We require data from the Mylar monitor to inform our UI design. We should also make this data available to others, since it will include general Eclipse usage statistics. In order to provide users with an incentive to share their (anonymous) usage data we should include personal interaction monitoring facilities.

Platform

The Eclipse Project DRAFT 3.3 Plan

Last revised 14:35 EST September 4, 2006 ((new) marks interesting changes)

    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.2, designated release 3.3.

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 all of the sub-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_3" in the Eclipse Project CVS repository.
  • Eclipse SDK (runtime binary and SDK for Equinox, Platform, JDT, and PDE) (downloadable).
  • Eclipse Platform (runtime binary and SDK for the Equinox and 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:

  • Thursday Aug. 10, 2006 - Milestone 1 (3.3 M1) - stable build
  • Friday Sep. 22, 2006 - Milestone 2 (3.3 M2) - stable build
  • Friday Nov. 3, 2006 - Milestone 3 (3.3 M3) - stable build
  • Friday Dec. 15, 2006 - Milestone 4 (3.3 M4) - stable build

Our target is to complete 3.3 in late June 2007. 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.3 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.3 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 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 (new)BEA JRockit 5.0,
for Microsoft Windows
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
Microsoft Windows XP Intel x86 Win32 (new)BEA JRockit 1.4.2,
for Microsoft Windows
Red Hat Enterprise Linux WS 4 Intel x86 GTK Sun Java 2 Standard Edition 5.0 Update 6
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 5.0
Red Hat Enterprise Linux WS 4 Intel x86 GTK (new)BEA JRockit 5.0,
for Linux x86
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 (new)BEA JRockit 1.4.2,
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.3 on Windows or Linux can be used to cross-develop QNX applications. (Eclipse 3.3 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.3 with 3.2

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

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

Source Compatibility: Eclipse SDK 3.3 will be upwards source-compatible with Eclipse SDK 3.2 except in the areas noted in the Eclipse 3.3 Plug-in Migration Guide . This means that source files written to use Eclipse SDK 3.2 APIs might successfully compile and run against Eclipse SDK 3.3 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.3 will be upwards workspace-compatible with Eclipse SDK 3.2 unless noted. This means that workspaces and projects created with Eclipse SDK 3.2, 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.3 and upgraded to a 3.3 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.3 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.3 plug-in developers are responsible for ensuring that their plug-ins recognize 3.2, 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.3 will be unusable with a product based an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.3 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 PMC of the Eclipse Project has identified six major areas of work, that will be the priorities for this development cycle. These areas will address the major themes identified by the Eclipse Requirements Council (Themes and Priorities v2.0).

Although there are four projects under the top-level Eclipse Project, there is a significant amount of commonality and shared effort between them. In general, many plan items involve coordinated changes to multiple components, and thus attempting to separate the items into sections based on sub-project leads to artificial distinctions between them (e.g. Platform Text vs. JDT Text, Platform Debug vs. JDT Debug, etc.).

In order to provide the clearest focus for our development effort, we have organized the items below into sections based on the work area they are intended to address. Items that apply to multiple work areas are categorized based on where the most effort is expected to occur. In all cases, the items listed reflect new features of Eclipse or areas where existing features will be significantly reworked. Numbers in parentheses link to bugzilla problem reports where progress on that item can be tracked and discussed.

The major work areas are:

Components

This work will enhance Eclipse's use of, and support for, software components, covering everything from component programming models such as Declarative Services, API tools, incremental building and fine-grained function delivery.

Committed Items (Components)

None at this time.

Proposed Items (Components)

((new) new) Improved support for provisioning. Eclipse has advanced quite quickly with new use-cases (RCP, Equinox, server side, etc.) and new technologies (e.g., OSGi and OSGi's MEG) coming into the picture. To date Update Manager has not been enhanced to support or exploit these changes. In 3.3 we will investigate provisioning support for enhanced workflows, the ability to update the so-called "root files" (e.g., startup.jar, eclipse.exe), improved efficiency (download and disk footprint), support for right-grained discovery and acquisition of function as well as integration with differing repository types. This effort also includes enhancements to the tooling around provisioning. [Update] (154077)

((new) new) API tools. More components means more API and an elevated need for solid APIs, evolved but compatible APIs and the correct and understood use of APIs. This cannot be achieved without supporting tooling. Today PDE includes sophisticated support for classpath management and access rule management based on information in the manifest of bundles to facilitate the capture of package and class references. In 3.3. we will expand this to cover finer-grained API contracts (e.g., clients should not call foo() or extend Bar). Similarly, developers will be given effective mechanisms for discovering, visualizing and minimizing dependencies in their code, bundles produced by third parties and non-bundled code libraries. Tooling in support of checking and managing the evolution of component and package version numbers will also be supplied. [PDE] (154078)

((new) new) Bundle/Module Development Tools. In 3.1 and 3.2 PDE made gigantic strides in support for traditional OSGi bundle development. Even still, in 3.3. we will improve various workflows and classpath management strategies to promote the development of robust and independent right-grained components. This covers everything from increased quick-fix and manifest editing support to deeper integration with JDT (e.g., support for searching JARs that are not in the workspace without implicitly importing the JARs). In addition, as JSR 291 evolves in the Java SE 6 time frame, PDE will be there to provide developer support. 3.3 will include tooling around OSGi Declarative Services and the new application model as well as improved support for launching other frameworks, Java applications with bundle based classpaths and "hot launching" frameworks. [PDE] (154079)

((new) new) Target Provisioning. Currently, users wanting additional function supplied by others must manually acquire and install these additional bundles in their target platform. This process is tiresome and error-prone. As an extension to the proposed provisioning work, we will add the ability to provision targets directly from bundle repositories as well as from other locations on the local machine. As part of this the mechanism by which source is packaged, acquired and looked up will be reviewed and streamlined. [Update] (154081)

((new) new) Bundle Management. Managing even modest systems of bundles can be complex and error prone. There are several places in PDE where developers need to list or select sets of bundles (e.g., launch configurations, target setup, etc). In many cases the environment already includes relevant grouping constructs (e.g., features, working sets, bundle groups). PDE should surface these to developers in a clear, consistent and pervasive fashion. [PDE] (154082)

((new) new) Incremental Plug-in Build. With the increase in plug-ins coming from and going to third parties the development cycle needs to be more incremental. In the Eclipse project itself we have started to consume pre-built plugins such as ICU4J and SSH2. This trend is likely to continue as, for example, Apache seeks to deliver their libraries as bundles and more people look to consume individual bundles/components from Equinox and similar projects. As such, the build process should support the incremental building of plug-ins (that is building plugins individually) based on a set of pre-built plugins kept in some sort of provisioning repository. Plug-ins coming out of the build should feed into said repository to be used as a base for future builds. This ability will in turn enable the more frequent building of whole systems (since you build only what has changed) and simplify incremental, milestone and release build cycles. [PDE Build] (154083)

((new) new) Application Model. The OSGi R4 MEG specification includes an application model that significantly decouples the application from the rest of the system. The net result is OSGi (and thus Eclipse) as a more flexible application container, for example allowing multiple applications to run concurrently and improved lifecycle around the application. These characteristics are important both to the manageability of the system (e.g., simplifying and clarifying the shutdown process) but also to various RCP scenarios such as Kiosk-mode and Application Container models. In 3.3 we will implement and adopt the MEG application model. [Equinox] (154084)

((new) new) OSGi R5 Specification Work. Much of the success Eclipse has enjoyed with OSGi comes from the fact that the Eclipse community has played a very active role in the evolution of various OSGi specifications. With increased interest in OSGi and Java modularity (see JSR 277, JSR 291 and JSR 232) this participation has never been more important. In addition to promoting Eclipse use-cases and the evolution of these standards to benefit Eclipse, there are a number of gaps in the OSGi specifications that Eclipse is currently filling in specific ways and should be addressed in R5. For example the management of API in metadata (x-friends and x-internal), integration techniques for third party and legacy code, in-place execution of bundles, basic notions of data location, etc. The Equinox team will continue their active participation in these specification processes and keep Eclipse on the leading edge of Java componentization. [Equinox] (154085)

((new) new) Server side support. First it was tools, then it was applications, now server-side programmers are waking up to the power of componentization delivered by Eclipse and OSGi. In the 3.2 cycle an Equinox incubator was started to investigate the use of Eclipse on the server. It started as a very modest servlet bridge allowing Eclipse to run inside a servlet engine and handle servlet requests and has been evolving into a full-blown appreciation of what it means to componentize server software. There are many possible directions here and there is no way the Equinox team proper will be able to track, support and participate in all. However we will spend time understanding the basic requirements as they apply to the base framework and add-on services and look to support the use-cases presented by various other Eclipse projects that are adopting Eclipse on the server (e.g., ECF, ECP, Corona). [Equinox] (154087)

Defered Items (Components)

None at this time.

(End of items for Components.)

Consumability

This work will make it easier for users to get Eclipse, install it on their systems, and configure it for their use. It will also enhance the error handling and reporting mechanisms to make it easier to service Eclipse in the field. Finally, it will improve the scalability and performance of Eclipse, to provide a better experience for users working with many plug-ins and large data sets.

Committed Items (Consumability)

None at this time.

Proposed Items (Consumability)

((new) new) Improve the launching experience. We will look for ways to improve the current launching experience. This may include efforts such as using SWT to build the splash screen, improving the look and utility of the workspace launcher, supporting "fast switching" between workspaces, and simplifying the experience for first-time users. [SWT, Runtime, Workspace, UI, UA] (154088)

((new) new) 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 can diagnose unexpected behavior such as slow-downs or exceptional memory use. Error handling is done in a variety of ways within the platform which are not extensible to RCP applications. An improved story would allow for the inclusion of application defined error support (such as a link to a support centre for the product) and remote monitoring/inspection of system health and would tie the current error reporting story together into a solution with a more consistent look and fewer error reporting paths for developers. [Runtime, UI] (154090)

((new) new) Managing and sharing settings. Currently settings are either scoped at the workbench/workspace level or the project level. However, there are cases where associating settings with other scopes, such as a working set or perspective, would be beneficial. Similarly, a product should be able to specify the default settings for a particular perspective. We will also look for ways to simplify how we share settings and other interesting state, such as breakpoints, bookmarks, perspectives, key bindings, etc. [Runtime, Workspace, UI] (154097)

((new) new) Customization. Eclipse lacks customization capabilities aimed at end users and product packagers. More generally, component development and use is fraught with producer/consumer problems. Component producers implement solutions that address a number of use-cases and scenarios but inevitably consumers come up with additional, sometimes quite divergent requirements. We will investigate mechanisms and facilities that allow component consumers to "override" or replace metadata specifications in the components they are consuming. Such mechanisms would, for example, allow consumers to configure menus, tool bars, and perspectives of their Eclipse installation as well as refine plug-in dependency declarations. [Runtime, UI] (154099)

((new) new) Platform level proxy settings. There are at least three proxy settings pages in Callisto. We will work with the Eclipse community to make sure that the core capabilities from these pages are made available at the Platform level, as a single settings page that can be consumed by all. [Runtime, Team, Update, UI] (154100)

((new) new) GTK Printing. We will provide printing support on GTK. [SWT] (154101)

((new) new) Ship Finer-grained Components. The Eclipse project produces three major outputs, the Platform, JDT and PDE. These are exposed as zips on download sites and features on update sites. Those wanting to get just part of one of these components (e.g., Help, Update, JDT Core) must first discover which zip or feature contains the desired function, acquire that container and finally identify and extract the desired plug-ins. To make this easier we will revise the grouping structure to capture more independent and re-usable components. [All components] (154102)

((new) new) Search based navigation. Because traditional navigation-by-browsing does not scale to large data sets, we should generalize and extend the existing search-based rapid navigation mechanisms (e.g. "Quick Find Class"). [UI, UA] (154104)

((new) new) Performance focus. We must continue to improve overall performance and memory consumption, with a particular focus on working with large numbers of plug-ins and large amounts of data. [All components] (154106)

Defered Items (Consumability)

None at this time.

(End of items for Consumability.)

Java

The Eclipse Java Development Tools are the premier Java development environment in the industry today. We must address the new capabilities of Java SE 6 and continue to refine and extend the features JDT provides to maintain its leadership position.

Committed Items (Java)

None at this time.

Proposed Items (Java)

((new) new) Enhance launching support. We should simplify the launch experience for novice users with single click context sensitive launching, simple launch configurations managed via resource properties, and user configurable toolbar buttons to invoke favorite launch configurations. For advanced users, we should allow plug-ins to contribute additional pages to launch configurations so that plug-in specific information (such as profiling and code coverage settings) can be associated with each configuration. [Debug] (154107)

((new) new) More refactorings. We will finish the 'Fix Deprecation' refactoring that didn't make it into 3.2, and add the new refactoring 'Replace Invocation'. More refactoring API will be offered in the plug-in org.eclipse.jdt.core.manipulation so the refactoring infrastructure can be used with a UI. [JDT UI] (154108)

((new) new) Extend Clean Up. Add formatting, organize import and sort members to 'Clean up', offer clean up profiles, and invoke clean up on user defined events. [JDT UI] (154109)

((new) new) Enhance Annotation Processing Tooling. An APT command-line tool should be provided as a complement to the batch compiler and/or Ant javac adapter, in addition to the Java IDE support within release 3.2. APT should also support the new standard Annotation Processing API (JSR 269) introduced in Java SE 6, as opposed to the provisional API from Sun introduced in Java SE 5 that is currently implemented. Also, the APT integration in IDE should be improved in various areas, including editor reconciling and code assist. The editor reconciling experience should work correctly even if the Java builder is not active. Currently, if a processor generates types, those types are ignored during reconcile. Instead, they should be modeled using working copies, and provide the same level of functionality as JDT when autobuild is turned off. Also, on the code-assist front, we should provide a simple API for processors to supply domain specific knowledge to completions inside annotation values. [JDT APT] (154110)

((new) new) Compiler API (JSR 199). In order to conform to the forthcoming tool API for compilers (JSR 199), the Eclipse compiler should provide a front-end implementing the tool API included in Java SE 6. [JDT Core] (154111)

((new) new) Add more class file targets for compiler. The compiler should support more configurable class file targets, including CLDC 1.0, CLDC 1.1 and possibly JSR 14 (generics experimentation for 1.4 VMs). [JDT Core] (154113)

((new) new) Support for Java SE 6 debug features. Implement new Java SE 6 features in the Eclipse Java Debug Interface (JDI) client including support for heap walking (retrieve instance counts, all intances of specific types, and all references to an object), forcing an early return from a method with a specific return value, breakpoints for monitor acquisition and release, access to the constant pool, and improved class prepare event filtering. [JDT Debug] (154115)

Defered Items (Java)

None at this time.

(End of items for Java.)

Vista

Microsoft Vista is a significant new desktop platform that we expect will become available during this development cycle. We should fully support running the current, win32-based version of Eclipse on Vista. We should also port SWT to WinFX and the Windows Presentation Framework.

Committed Items (Vista)

None at this time.

Proposed Items (Vista)

((new) new) Fully support the win32 version of SWT on Vista. We should ensure that applications built on the win32 version of SWT work as well as any other win32 API based application on Vista. This will increase our testing and support effort and potentially require new development to work around platform specific differences. [SWT] (154116)

((new) new) Port SWT to WinFX and WPF. We should port SWT to WinFX and the Windows Presentation Framework. Since 64-bit systems are becoming increasingly prevalent on the desktop, we should ensure that this port is both 64-bit and 32-bit capable. [SWT] (154117)

((new) new) Generalize the win32 version of SWT to win64. We should merge the work being done by the Eclipse community to implement a win64 implementation of SWT into the main win32 code base. This will require extensive review of the new code and a significant effort to merge and test the pervasive changes. [SWT] (154118)

Defered Items (Vista)

None at this time.

(End of items for Vista.)

UI Evolution

The goal of this work is to provide a better basis for building modern, rich user-interfaces, by addressing areas where more flexibility and more consistency are needed. We will use these capabilities to refine the user-interface of the Eclipse IDE. In addition, we will implement of the most requested missing IDE productivity features.

Committed Items (UI Evolution)

None at this time.

Proposed Items (UI Evolution)

((new) new) Implement missing text editor productivity features. We should provide some of the long awaited productivity features that the community has voted for. Examples include double-click-drag to select multiple words, triple-click, extensible hyperlink support and spell checking. We should also improve the current search/replace dialog. [Platform Text, Platform UI, SWT] (154119)

((new) new) Improve workbench usability. We should review how users interact with the workbench, such as how editors, views, and other screen real-estate are managed (e.g. fix the broken minimize), and find ways to make this a better experience for them. This includes improving the new trim support by allowing the end user to hide/show, close and otherwise configure trim items, improving navigation from hovers (e.g. quick diff), making fast views more flexible (fast views on all sides, fast view orientation affinity, fast view bars show text option). [Platform UI, Platform Text, JDT UI, JDT Text] (154120)

((new) new) Improve multi-instance view management. Views such as Search and Synchronize use a drop-down menu to manage multiple pages. Another possibility would be to use multiple view instances. However, the presentation and management of these two approaches are different. Multiple view instances should support different view presentations. That is, the user (or product) should be able to decide whether multiple views use tabs or a drop-down menu. There are also shortcomings in multi-view management (e.g., views are managed at the perspective level but some tooling may require the ability to close a particular view in all perspectives). [UI] (154121)

((new) new) Investigate background saving of editors. Modern applications allow editing sessions to be saved in the background, allowing the user to continue editing or close the editor without waiting. We should investigate whether this style of interaction can be built on top of the Eclipse editor framework. [Platform Text, JDT Text, Platform UI] (154122)

((new) new) JFace Enhancements. Ensure that the reusable components in JFace fully support the SWT widget set, such as support for the new custom draw capabilities of the Table and Tree widgets. Also, implement some of the components that we do not use in the SDK currently that the community is requesting. Some examples include: spinners, secure editors (such as password entry fields) fields that enforce a format (such as fields for currency and percentages), etc. [Platform UI, SWT] (154123)

((new) new) Mozilla Everywhere. For situations where the existing, platform-browser-based Browser control is not sufficient, we should support embedding of Mozilla on all platforms. This would allow developers to implement code that worked against a common back end, so that they could access a common DOM, or surface the browser's HTML editing support. [SWT] (154124)

Defered Items (UI Evolution)

None at this time.

(End of items for UI Evolution.)

API

This work area deals specifically with issues concerning the application programming interfaces provided by the Eclipse Project. We will identify API whose function has been superceded, and ensure that the SDK does not depend on this API. We will encourage adoption within the SDK of some of the more recent additions to Eclipse, such as the command framework, Equinox preferences, tabbed properties and the common navigator. We will work with the community to ensure that needed functionality is made available as API, when it reaches appropriate levels of maturity.

Committed Items (API)

None at this time.

Proposed Items (API)

((new) new) Generalize editor annotation and ruler support. We should allow plug-ins to contribute additional vertical rulers to show additional information (e.g. code coverage). We should support live annotate "color by age" in addition to "color by contributor". [Platform Text] (154125)

((new) new) Adopt the Eclipse File System. We should ensure that use of the Eclipse File System is pervasive in the platform, and remove any barriers that prevent it from being more widely adopted by the community. For example, we should provide IFileStoreEditorInput and a matching default implementation. [Workspace, UI, Platform Text] (154126)

((new) new) Adopt the new UI features. We should adopt the following items across the entire SDK UI: the new command framework, preference initializers, field assist, SWT column sort indicators, working sets, tabbed properties view and the common navigator. [UI, JDT UI, PDE, Team, Text] (154127)

((new) new) Provide access to more native controls. We should provide access to more of the native controls that are available on each platform, such as date and time pickers, and table header widgets. In addition, we should enable more features of existing native controls, such as table wrapping on Windows. [SWT, UI] (154128)

((new) new) Custom widget API support. Investigate ways to simplify the process of writing custom widgets, including making available, as API, some of the currently internal capabilities of the custom widgets implemented in the SDK, such as drag under feedback for drag & drop. [SWT] (154129)

((new) new) Finish re-work of commands and key bindings. In 3.2, we built some important infrastructure that will allows us to rationalize our commands and key bindings story. We need to complete this effort, making sure the new story supports all of the existing functionality (e.g action sets), and migrate over to the new support. We also need to make it easier to add and edit key bindings. [UI] (154130)

((new) new) JFace data binding. In 3.2, we developed a data binding framework for JFace but did not make it generally available. We should continue to work towards providing a public API for this framework and investigate how it will be delivered and used within the SDK. [UI] (154132)

((new) new) Improve compare. The Compare plugin has not undergone much work in the last few releases and is showing it. From an architectural standpoint, there are several Compare internals that need to be made API in order to properly support clients and there are also several polish items that have been identified by Eclipse development teams. In addition, new ISaveable support was added in 3.2 and we should investigate integrating this into Compare. From a usability standpoint, the compare editor uses a custom viewer for content which appears similar to the related editor but has a reduced capability which is often confusing for users. Smaller usability issues involve breaking out the outline from the editor into the Outline view. There is supported by compare but is not used by Team or other Platform clients. [Team] (154133)

((new) new) Graphics Improvements. The SWT graphics layer should provide support for fractional line widths, dashes and fonts, the ability to flatten paths, image loading/saving improvements, and other similar enhancements. [SWT] (154134)

((new) new) APIs for custom debugger integration. Publish public APIs based on the provisional APIs introduced in 3.2 to support custom debugger integration. Features include flexible hierarchy in debug views; asynchronous, cancellable interactions when retrieving content and labels; model-driven view updates; a debug context service for retargettable actions, flexible view wiring and pluggable source lookup. [Platform Debug] (154135)

Defered Items (API)

None at this time.

(End of items for API.)

Appendix 1: Execution Environment by Plug-in

In the table below, the "3.3 EE" ("3.3 Execution Environment") column indicates the minimum Java class library requirements of each plug-in for the 3.3 release, where the value is one of:

Entry Meaning
M1.0
OSGi Minimum Execution Environment 1.0 - This is a subset of the J2ME Foundation class libraries defined by OSGi to be the base for framework implementations. See the OSGi specification for more details.
M1.1
OSGi Minimum Execution Environment 1.1 - This is a subset of the J2ME Foundation class libraries defined by OSGi to be the base for framework implementations. See the OSGi specification for more details.
F1.0
J2ME Foundation 1.0 - indicates that the plug-in can only be run on Foundation 1.0 or greater. Note that with the exception of some MicroEdition IO classes, Foundation 1.0 is a subset of J2SE 1.3.
F1.1
J2ME Foundation 1.1 - indicates that the plug-in can only be run on Foundation 1.1 or greater. Note that with the exception of some MicroEdition IO classes, Foundation 1.1 is a subset of J2SE 1.4.
1.2
J2SE 1.2 - indicates that the plug-in can only be run on JSE 1.2 or greater.
1.3
J2SE 1.3 - indicates that the plug-in can only be run on JSE 1.3 or greater.
1.4
J2SE 1.4 - indicates that the plug-in can only be run on JSE 1.4 or greater.
1.4/1.5
Indicates that the plug-in can run on JSE 1.4 or greater, but provides enhanced functionality when run on J2SE 5.0.
1.5
J2SE 5.0 - indicates that the plug-in can only be run on JSE 5.0 or greater.
1.6
J2SE 6.0 - indicates that the plug-in can only be run on JSE 6.0 or greater.
n/a Unknown at the time of this revision.

Table of minimum execution environments by plug-in.

Plug-in
3.3 EE
org.apache.ant
1.2
org.apache.lucene
n/a
org.eclipse.ant.core
1.4
org.eclipse.ant.ui
1.4
org.eclipse.compare
n/a
org.eclipse.core.boot
1.4
org.eclipse.core.commands
F1.0
org.eclipse.core.expressions
F1.0
org.eclipse.core.filebuffers
1.4
org.eclipse.core.filesystem
1.4
org.eclipse.core.resources
1.4
org.eclipse.core.resources.compatibility
1.4
org.eclipse.core.runtime
F1.0
org.eclipse.core.runtime.compatibility
1.4
org.eclipse.core.variables
1.4
org.eclipse.debug.core
1.4
org.eclipse.debug.ui
1.4
org.eclipse.help
F1.0
org.eclipse.help.appserver
F1.0
org.eclipse.help.base
F1.0
org.eclipse.help.ui
F1.0
org.eclipse.help.webapp
F1.0
org.eclipse.jdt
1.4
org.eclipse.jdt.core
1.4
org.eclipse.jdt.apt.core
1.5
org.eclipse.jdt.apt.ui
1.5
org.eclipse.jdt.debug
1.4
org.eclipse.jdt.debug.ui
1.4
org.eclipse.jdt.doc.isv
n/a
org.eclipse.jdt.doc.user
n/a
org.eclipse.jdt.junit
1.4/1.5
org.eclipse.jdt.junit.runtime
1.4/1.5
org.eclipse.jdt.launching
1.4
org.eclipse.jdt.source
n/a
org.eclipse.jdt.ui
1.4/1.5
org.eclipse.jface
F1.0
org.eclipse.jface.text
1.4
org.eclipse.ltk.core.refactoring
1.4/1.5
org.eclipse.ltk.ui.refactoring
1.4/1.5
org.eclipse.osgi (system.bundle)
M1.0
org.eclipse.osgi.services
M1.0
org.eclipse.osgi.util
M1.0
org.eclipse.pde
1.4
org.eclipse.pde.build
1.4
org.eclipse.pde.core
1.4
org.eclipse.pde.doc.user
n/a
org.eclipse.pde.junit.runtime
1.4
org.eclipse.pde.runtime
1.4
org.eclipse.pde.source
n/a
org.eclipse.pde.ui
1.4
org.eclipse.platform
F1.0
org.eclipse.platform.doc.isv
n/a
org.eclipse.platform.doc.user
n/a
org.eclipse.platform.source
n/a
org.eclipse.platform.source.*
n/a
org.eclipse.rcp
F1.0
org.eclipse.rcp.source
n/a
org.eclipse.rcp.source.*
n/a
org.eclipse.sdk
n/a
org.eclipse.search
1.4
org.eclipse.swt
M1.0
org.eclipse.swt.*
M1.0
org.eclipse.team.core
1.4
org.eclipse.team.cvs.core
1.4
org.eclipse.team.cvs.ssh
1.4
org.eclipse.team.cvs.ssh2
1.4
org.eclipse.team.cvs.ui
1.4
org.eclipse.team.ui
1.4
org.eclipse.text
1.4
org.eclipse.tomcat
n/a
org.eclipse.ui
F1.0
org.eclipse.ui.browser
1.4
org.eclipse.ui.cheatsheets
F1.0
org.eclipse.ui.console
1.4
org.eclipse.ui.editors
1.4
org.eclipse.ui.externaltools
1.4
org.eclipse.ui.forms
F1.0
org.eclipse.ui.ide
1.4
org.eclipse.ui.intro
F1.0
org.eclipse.ui.navigator
1.4
org.eclipse.ui.navigator.resources
1.4
org.eclipse.ui.presentations.r21
1.4
org.eclipse.ui.views
1.4
org.eclipse.ui.win32
1.4
org.eclipse.ui.workbench
F1.0
org.eclipse.ui.workbench.compatibility
1.4
org.eclipse.ui.workbench.texteditor
1.4
org.eclipse.update.configurator
F1.0
org.eclipse.update.core
F1.0
org.eclipse.update.core.linux
F1.0
org.eclipse.update.core.win32
F1.0
org.eclipse.update.scheduler
F1.0
org.eclipse.update.ui
F1.0
org.junit (old)
1.4
org.junit (JUnit4)
1.5
startup.jar
F1.0

Test and Performance Tools Platform (TPTP)

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

Last revised 10/23/2006 09:23 PM Pacific Time ( marks interesting changes since September 2006)

    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.3 release.

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.3 release is targeted for general availability on 27-Oct-2006.  All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations.  The first iteration is dedicated to defect fixing, automation of regression testing, and measuring and increasing test coverage for public API. There will be no enhancements committed to CVS HEAD stream until end of iteration #1, except new features that were made available as technology preview in TPTP 4.2 release. In iteration #2, 4.2.1 release branch will be created in CVS and enhancements in plan for 4.3 release will be allowed to be committed to CVS HEAD stream. Iteration #3 is for shutting down development and get ready to release 4.3 GA.

Release Milestones

Milestone Date Description
Iteration 1 Friday, 04-Aug-06 Stable build - bug fixes only (CVS stream common with 4.2.1)
Iteration 2 Friday, 22-Sep-06 Stable build - enhancements and bug fixes
Iteration 3 Friday, 17-Nov-06 Stable build - shut down
  Monday, 04-Dec-06 General Availability

For a detailed development schedule of TPTP 4.3 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
  • 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.3 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.3 is tested and validated on the following target reference platforms (this list may be updated over the course of the release cycle):

TPTP Agent Controller Reference Platforms
Processor architecture Operating system
Intel IA32 Red Hat Linux v7.1, v7.2, v7.3, v8.0
Intel IA32 Red Hat Linux Advanced Server v2.1
Intel IA32 SuSE Linux v7.2, v7.3
Intel IA32 SuSE Linux Enterprise Server (SLES) v7, v8
Intel IA32 Windows 2000 Advanced Server (service pack 2)
Intel IA32 Windows 2000 Professional (service pack 2)
Intel IA32 Windows 2000 Server (service pack 2)
Intel IA32 Windows NT 4.0 (service pack 6a)
Intel IA32 Windows Server 2003
Intel IA32 Windows XP Professional
Intel EM64T Red Hat Linux Advanced Server v3
Intel EM64T Windows 20003 Server (service pack 1)
Intel IPF Red Hat Advanced Server v3
Intel IPF Windows 20003 Server (service pack 1)
iSeries OS/400 V5R1, V5R2
PA-RISC HP-UX v11.0, v11i
RS/6000 AIX v4.4.0, v5.1, v5.2
SPARC Sun Solaris v8, v9
zSeries z/OS V1R7
zSeries SuSE Linux Enterprise Server (SLES) v8
PowerPC/64-bit Red Hat Enterprise Linux AS release 3

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.3 will be compatible with TPTP 4.2.  The following specifies details of the various aspects of release compatibility.

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

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

  • Source Compatibility: TPTP SDK 4.3 will be upwards source-compatible with TPTP SDK 4.2. This means that source files written to use TPTP SDK 4.2 APIs might successfully compile and run against TPTP SDK 4.3 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.3 will be upwards workspace-compatible with TPTP SDK 4.2 unless noted. This means that workspaces and projects created with TPTP SDK 4.2 can be successfully opened by TPTP SDK 4.3 and upgraded to a 4.3 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.3 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, log analyzer 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.3, and expect need for continuing this focus beyond 4.3.

  • 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 top-level project is is comprised of four projects, managed in a coordinated fashion, across which the plans items are allocated.  TPTP projects 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
In Plan Support existing RAC clients and agents on the Linux IA32 platform using the new Agent Controller technology through compatibility layers(125103).
In Plan TPTP profiler (based on JVMTI) will be further improved in this release cycle with a heap profiler (147653) thread profiler (147654), and improved performance summary information (147658)
In Plan This requirement is to make the Log Analyzer UI format-agnostic when displaying Common Base Events as the event format will change and evolve over time. Any view, dialog, or editor that currently displays Common Base Events should display the events in a consistent manner with consistent naming. 71682
In Plan Provide the Log Analyzer functionality available in TPTP as an RCP application. The TPTP Log Analyzer will be restructured so that it can be packaged as a Rich Client Platform application. The RCP application will provide log visualization, analysis and correlation. 134531
In Plan The TPTP log analyzer provides a set of useful services to analyze log files. Most of these services are tightly tied to the log and trace analyzer user interface. It is required to decouple these services from the UI so that consuming products can reuse the above functionality. This enhancement is used to define a set of interfaces to expose the log analysis and correlation services available in the TPTP Log Analyzer function. 143766
Helpwanted
We are investing in automating post-build steps in deploying and executing regression tests. This has been dire need for the project and should positively impact quality and productivity. Automate the deployment and set up of Agent Controller on all platforms (144958)
Helpwanted This enhancement will improve the usability of dynamic probekit feature by automatically deploying the support class files that contain byte code for the user defined probes (143251)
Helpwanted Web document for creating custom profilers with Probekit 147450
Helpwanted Explore design approaches to improve scalability and responsiveness of EMF-based data models for trace and test tools.[Trace Model 147656] [Test Model 144950]
Helpwanted Provide capability in the agent framework to dynamically determine if the data collection services are available to an agent. The data collection services include agent controller and file transfer service. 142742

 

TPTP Testing Tools Project Plan Items
Status Description
In Plan Improve JUnit integration between TPTP and JDT. Allow the JUnit user to have the same experience, once TPTP is installed, as he/she used to have in Eclipse SDK, with the possibility of executing his/her JUnit tests in the TPTP framework. Any JUnit test would be edited and created as usual, and still it would be integrated with other types of TPTP tests, and could be executed in the TPTP framework. (90628) [Theme: Appealing to the Broader Community, Simple to Use]
In Plan Provide a generic Java API recorder Based on the generic recording facility provided in TPTP v4.1+ (see enhancement #74926), provide a generic recorder to record Java API invocations to create a test. The generic recorder could leverage the TPTP Probe Kit to instrument target APIs to capture invocations based on predefined criteria. (119688) [Theme: Design for Extensibility: Be a Better Platform]
In Plan Provide the concept of an object mine inside each test suite The object mine will keep track of a single id of an object irregardless of the number of times it occurs in the test cases owned by the test suite. The user will also be able to include external object mines (i.e. object mines owned by other test suites) and contribute any newly detected objects to an external object mine. (144763) [Theme: Appealing to the Broader Community, Simple to Use]
Helpwanted Providing better means for the user to specify a workspace location An extra page specific to the auto GUI test suite should be included in the launch configuration dialog to allow the user to specify a workspace and the plug-ins that they wish to include in the launched workbench. (109880) [Theme: Appealing to the Broader Community, Simple to Use]
Helpwanted Automated Documentation Generation The feature being proposed it to utilize the GUItester to create SIMPLE documentation (in HTML format, or another generic output of the users choosing) that outlines the (1) name of the UI test; (2) the series of steps taken in the UI test; (3) screenshots at every possible step during the test. (110108) [Theme: Appealing to the Broader Community, Simple to Use]
Helpwanted Support RCP applications for recording and playing back GUI test cases A common feature that users ask for is to have support in recording and playing back test cases in an RCP application. (114159) [Theme: Rich Client Platform]
Helpwanted Generic Recorder Framework improvements. Support for launching and controlling two or more recorders or recording agents in parallel. Support for launching Java applications for recording without creating/using an Eclipse launch configuration. Support remote recording via the Agent Controller. Provide an extension point for user-defined annotations to a recording session. Support (e.g. model loading) for recorders to emit standard trace model events. (145146) [Theme: Appealing to the Broader Community, Simple to Use]
Helpwanted The test launch configuration needs to have the means for users to specify JVM argument. Support for a standard way for users to specify JVM arguments for test execution. Provide an UI for the user to specify zero or more JVM arguments and an API for JUnit-based test runners to access these JVM arguments for launching the Java test process. (143121) [Theme: Design for Extensibility: Be a Better Platform]

 

TPTP Tracing And Profiling Tools Project Plan Items
Status Description
In Plan Providing better analysis views for analyzing execution statistics The following enhancements should make analysis of execution statistics easier: Easily identify the method that has had the maximum base/cumulative time. Quick hover explanation in the view or better naming for the base or cumulative time. The method statistics view should simply should show the stack for a particular method invocation. (147930) [Theme: Appealing to the Broader Community, Simple to Use]
In Plan  Provide better abstraction and navigation means in the Trace views The following feature tries to outline some improvements that may help to abstract and navigate the profiling data: Provide a find operation under the execution time statistics, memory statistics, and code coverage view. Ability to bring deltas to the top or only showing deltas between refreshes Showing what’s changed when deltas are displayed Doing post filtration in the views Doing pagination in the tabular views Filtering methods that have a base/cumulative time that is less than a given threshold (147931) [Theme: Appealing to the Broader Community, Simple to Use]
In Plan  Using virtualization in stat views Virtualization can be used to reduce the amount of time required to show a large number of tree items. This can significantly help improve the performance of the execution stat view when it is viewed at the method level. (147933) [Theme: Scaling Up]
In Plan  Create Extension Point for ARM Factories Create a new extension point to allow user to define there own Application Resource Measurement Factories. The extension point would include transaction, metric, and reporting. (148048) [Theme: Design for Extensibility: Be a Better Platform]
Helpwanted Trace-related views should make use of view linking service Currently some views listen for selection events on other views and make use of this information to update their own selections to something related to the original selection. For example, if you have the log view and log interactions view open at the same time, and select a log record in one of them, the other view will automatically update and select that same log record, if it's there. All the views should use a standard view linking service to do this. (87605) [Theme: Design for Extensibility:Be a Better Platform]
Helpwanted Providing better analysis views for detecting memory leaks The following enhancements need to be made to make memory leak detection easier; Objects that are garbage collected need to be removed from the object reference view. Integrate the object reference view with the memory statistics view. Provide a dynamic chart that is updated when the heap size changes Enhanced look & feel of the object reference view. (147929) [Theme: Appealing to the Broader Community, Simple to Use]
Helpwanted Add a thread analysis and a call graph view A thread analysis view will allow users to resolve deadlock problems, thread starvation or other thread related issues. A call graph view will help to easily visualize application flow and critical paths that maybe the cause of a bottleneck. (147932) [Theme: Appealing to the Broader Community, Simple to Use]

 

TPTP Monitoring Tools Project Plan Items
Status Description
In Plan Improve usability of Stand-alone Generic Log Adapter package. 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. Also, to allow the packaged adapter configuration files to be used more easily in various applications, multiple outputters will be added to them, which can them be enabled or disabled depending on the application. (96433 and 126653) [Theme: Design for Extensibility: Be a Better Platform]
In Plan Provide sensor/extractor filtering capability in TPTP Generic Log Adapter log parsers. In TPTP 4.2 support was added to the Generic Log Adapter run-time for filtering at the sensor and extractor component level. This filtering capability will be exploited in the current TPTP provided log parsers to allow users to improve the performance of log parsing when only a subset of the log records is of interest. (141840) [Theme: Scaling Up]
In Plan Provide Rich Client Platform versions of Log Analysis tooling. Some users want stand-alone tools for log analysis. The TPTP Symptom Editor will be restructured so that it can be packaged as a Rich Client Platorm application. Also, some portions of the Log Analyzer will be restructured so it can be packaged as a Rich Client Platform application. (134532 and 134798) [Theme: Rich Client Platform]
In Plan Improve the Managed Resource Explorer. In TPTP 4.2 a technical preview was introduced for a generic Managed Resource Explorer. This tool will be improved in 4.3 so that it can become a full TPTP component. (145056, 145057, 145058, 150259, 150385) [Theme: Design for Extensibility: Be a Better Platform]
In Plan Add tooling to simplify creation of WSDM managed agents. In TPTP 4.2, a Managed Resource Explorer was added that allowed the developer to manipulate resources that sit behind a manageability endpoint. The Managed Agent explorer has plugins for JMX and WSDM. This feature for 4.3 would allow a developer to easily create WSDM based managed agents (referred to in WSDM as manageability endpoints) that are compliant with the WSDM 1.1 specification from OASIS. (142543) [Theme: Design for Extensibility: Be a Better Platform]
In Plan Improve the Monitoring Instrumentation tooling. In TPTP 4.2 a technical preview was introduced for tooling to instrument existing Java applications for monitoring. This support will be improved in 4.3 so that it can become a full TPTP component. ( 146272, 148042, 148044) [Theme: Design for Extensibility: Be a Better Platform]

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. The goal is clear backlog of major/critical/blocker defects and make reasonable progress on fixing as many as possible.

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

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

Web Tools Platform (WTP)

Eclipse Web Tools Platform 2.0 Plan - DRAFT


Please send comments about this draft plan to the wtp-pmc@eclipse.org or wtp-dev@eclipse.org mailing list.

This document lays out the feature and API set for the next release of Eclipse Web Tools, to be released as part of the Eclipse Europa Release, in June 2007, and usually called "WTP 2.0", for short.

This document is a draft and is subject to change, we welcome all feedback.

Web Tools 2.0 will be compatible with / based on the Eclipse 3.3 Release.

To ensure the planning process is transparent and open to the entire Eclipse community, we (the Eclipse Web Tools Requirement Group & the Web Tools 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 subprojects under the Eclipse Web Tools top-level project, including projects such as JSF and Dali that are currently in the incubator state. Each plan item covers a feature or API that is to be added to Web Tools, or some aspect of Web Tools that is to be improved. Each plan item will have 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.

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 priority or status of each plan item is noted:

High Priority plan item - A high priority plan item is one that we have decided to address for the release (committed).

Medium Priority plan item - A medium priority 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.

Low Priority plan item - A low priority plan item is one that we addressed for a release we will only address that item if one component has addressed all high and medium priority items.

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.

Help Wanted plan item - Typically something that started off as a Medium or Low priority, but marked "help wanted" as an acknowledgement that there are no core resources to implement the item, but if a company or person from the community wants to contribute it, then the core teams would be more willing than usual to consider any high quality patches or contributions made via bugzillas.

If not otherwise specified, an item should be assumed "medium priority". To be explicit, the appearance of an item in this draft plan should not be assumed as a commitment, but instead is simply "open development" in its form as "open planning".


Release deliverables

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

  • Source code release for Eclipse WTP Project, available as versions (e.g. tagged "R2_0_0" in the Eclipse WTP Project)
  • CVS repository
  • Eclipse WTP runtime binary and SDK download with all Eclipse pre-reqs (downloadable).
  • Eclipse WTP runtime binary and SDK download (downloadable).

In addition, the Eclipse WTP runtime binary and SDK will be available as part of the "Europa" update site.

Release milestones and release candidates

Release milestones will occur at roughly 6 week intervals in synchronization with the Eclipse Platform milestone releases (starting with M1) and will be compatible with Eclipse 3.3 builds. See [Europa Simultaneous Release] for the complete Europa schedule. The following are the approximate dates for WTP milestones. The approximate 1.5.x maintenance release dates are given too. The exact dates will be updated as the times grow nearer.


M1
Friday, Sep 1, 2006
Theme: run on Eclipse 3.3 stream
1.5.1
September 29, 2006
M2
Friday Oct 6, 2006
Theme: run on Eclipse 3.3 stream
1.5.2
October 31, 2006
M3
Friday Nov 17, 2006
Theme: Cleanup warnings, JUnits, Analyze Adopter Usage Reports
M4
Friday Jan 4, 2006
Theme Propose/implement APIs/Features
1.5.3
Friday February 16, 2007
M5
Friday Feb 23, 2007 (EclipseCon is 3/5)
Theme: provide good base for EclipseCon demos! :)
Most Function and API complete (e.g. 80%)
M6
Friday Apr 6, 2007
Theme: Function complete. API Freeze
RC1
Friday May 18, 2007
Theme: from M6 to RC1 will be polish, bug fixes, documentation
other RCs
if needed (June 22, latest final build)
Release
June 29, 2007

Target Operating Environments

Eclipse WTP is built on the Eclipse platform itself.

Eclipse WTP is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on Eclipse. The 2.0 release of the Eclipse WTP Project is written and compiled against an appropriate version of Java as specified by the Execution Environment of each plugin. In general, Java 5 of the Java Platform (Java SE 5.0) will be needed to use WTP as a whole, but, the Execution Environment will be specified for each plugin, starting at J2SE 1.4, which is the current requirement, and then only moved up to Java SE 5 when some change made that requires it. WTP adopters should expect that full functionality will require running on a Java SE 5.

Eclipse WTP is mainly tested and validated on Windows platforms, it should run on all platforms validated by the platform project:

Eclipse Target Operating Environments

Servers integrated into Eclipse WTP deliverables will be tested and validated on the same platforms listed above. Tests for other platforms will be relying on the community support.


Internationalization'

The Eclipse WTP 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. Other language support, if any, will rely on the community support.

Compatibility with Other WTP Releases

Project Compatibility:

  • Binary compatibility with 1.5 and 1.0 projects - users should need to take no special actions to use projects

from either of these WTP releases with the 2.0 version

  • WTP 2.0 should be able to open workspaces created with WTP 1.5
  • WTP 2.0 should be usable in a team environment where some team members use WTP 1.5 and team members share projects through a source code control system such a

CVS or Subversions. Specifically, A WTP 1.5 should be able to create a project, check it in to the repository. A WTP 2.0 user should be able to check it out, work on it, and check it back in. A WTP 1.5 should then be able to check it back out and continue to work it on.

  • By default, WTP 1.5 should work on projects created by WTP 2.0 users and shared via a repository. Artifacts created by WTP 2.0 that are consistent with 1.5

features should not break WTP 1.5, and where possible WTP 1.5 should either ignore or tolerate any new artifacts in WTP 2.0 and subsequent releases. Attempts to use (or convert to) new 2.0 functionality that cannot be made backwards compatible with 1.5 must be clearly identified in documentation.

API Compatibility:

  • WTP 2.0 will preserve (public, declared) API compatibility with the 1.5 release, both in terms of syntax and behavior
  • A plug-in that is developed on WTP 1.5 and that uses no internal methods should run correctly without recompilation on WTP 2.0
  • A plug-in that is developed on WTP 1.5 and that uses no internal methods should recompile without error on WTP 2.0
  • WTP 2.0 should provide migration notes and adequate notification and lead time to adopters for any internal code that is removed in WTP 2.0
  • WTP 2.0 should continue to provide adopters with the ability to register their code usage reports and to be consulted in any proposed changes to internal code.

WTP 2.0 will take into account adopter feedback on proposed changes to internal code, but reserves the right to change internal notwithstanding that feedback.

Eclipse WTP 2.0 deliverables will be compatible with Eclipse 3.3. No special attention will give for being compatible with previous Eclipse versions.

Eclipse WTP Subprojects

The Eclipse WTP consists of four subprojects. Each subproject is covered in its own section:

Web Standard Tools (WST)

J2EE Standard Tools (JST)

Java Server Faces Tools (JSF, incubating)

JPA (Dali/JPA, incubating)

AJAX Tools Framework (incubating)

The JSF, Dali, and ATF incubators SHOULD exit incubation and become normal components in WTP 2.0. A partial list of the new WTP components is:

  • JSF - org.eclipse.jst.jsf
  • Dali - org.eclipse.jst.jpa
  • ATF - org.eclipse.wst.js, org.eclipse.wst.ajax

Items listed reflect new features of the Web Tools Platform, or areas where existing features will be significantly reworked. Common goals are listed in the “Common goals” area.

TBD (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)

Note that JSF and JPA/Dali are incubating projects at the moment. Users should expect API and tool refinements in these areas, with a likelihood for more rapid (and extensive) revisions than in the base WTP code, along with initial API declarations in the 2.0 release.

Major themes

Improve Quality

Focused effort will be made to reduce bug backlog, improving test coverage, performance and performance testing, ISV documentation and examples, usability and UI consistency.

Adopter readiness

  • Extensibility
Provide extension points for adopters to add-in implementation functionality, such as for JEE5 features, publishing support, add to project creation pages, etc.
  • productization support [125751]
  • Componentization
improve feature split Subsystem and Features document
  • improve API coverage
convert provisional APIs in a careful, well reviewed way, to minimize adopter breakage

Improved Provisioning of Third Party Content

  • Participate in Orbit project to move our commonly needed third-party content to a common Eclipse repository.
  • help create remote Update Manager sites hosted by providers of third party content required by WTP to streamline the process of adopting new versions
users should be able to acquire revisions of third party content in a more timely fashion
begin by creating a common site at Apache for components such as Axis2, Woden, Tomcat, Geronimo
  • maintain and expand current site at SourceForge as required
  • create new site at ObjectWeb for Jonas

Help

  • adopt DITA for Help content
  • work with DITA-OT project at SourceForge to improve integration of build process with PDE

Web Standard Tools subproject

XML Editing

  • Improve Code folding
  • Migrate to Platform Undo (IOperationHistory)
  • Improved formatting, e.g. whitespace handling, WYSIWYG (for DITA, DocBook, etc.)
  • Run in Eclipse RCP
  • Large document performance enhancements

Architectural harmonization

DTP

Remove all Data access tools from WTP and instead use the corresponding components from DTP. We should take a two-phase approach.

  • Phase 1 - Achieve functional parity with WTP 1.5, i.e. get back to where we currently are, but using DTP.
  • Phase 2 - Exploit new DTP capabilities. DTP has much broader scope than the WTP 1.5 Data tools, e.g. in connection management, server exploration. We need

to do an architectural assessment of current WTP capabilities and adopt superior alternatives available in DTP.

WTP currently has only a small dependency on RDB, which might be migrated to DTP or, perhaps, will be replaced by a more a generic, loose, optional dependency.

JPA (Dali), however, will have a stronger dependency on DTP, so, DTP will, in the end, be listed as one of the pre-reqs for WTP as a whole. (But, the goal is, if JPA is not installed then DTP will not be required).

STP

Investigate areas of overlap with STP, especially in the areas of Web services, and ensure that existing WTP components can be extended as required by STP.

TPTP

Improve integration with TPTP, especially in the area of profiling servers.

PHP Tools Project

Investigate if the Apache Web server adapter should be moved into wst.server. Investigate if other generic components currently in the PHP project should be moved in WTP.

Need to investigate and support their use of our SSE Incremental DOM parser and A.) not break them :) or B.) provide API.

Web Services Support

  • Provide extensibility for providers of web service implementations
  • New WS-I Profiles, e.g. RAMP
  • WS Security
  • WS Policy
  • Axis 2.0
  • SOAP 1.2
  • WSDL 2.0 - adopt Apache Woden 1.0

J2EE Standard Tools

Java EE 5

  • JPA/Dali (Draft Milestone Plan)
  • JSF
    • JSF 1.2
  • JSP
    • Complete and Improve JSP 2.0 support
    • Support JSP 2.1
  • Provide extensibility for providers of JEE5 implementations
  • Java EE 5 models - the models must be upgraded to handle Java EE 5 without ANY API breakage. Existing clients MUST continue to work without recompilation.

If existing clients are recompiled with the new model, then compilation errors MUST NOT occur (note: we assume that existing clients will not break in any way if they only use the published API - code that relies on internal interfaces MAY break)

  • investigate: import a JEE5 project (help wanted)
  • investigate: export/publish a JEE5 project (help wanted)
  • validate a JEE5 project (help wanted)
  • JSR 175 - support Java EE 5 specifications for annotation based programming, e.g. for EJB 3.0, JPA, Web services
    • JSR 181 - Web Services
    • JSR 220 - EJB 3.0, JPA

Web Services

  • JSR 109 - for Web container
  • support for generic, compliant runtime, e.g. hosted at GlassFish

Server Runtime

  • JSR 88 Support, Advanced Server Support for one/multiple open source J2EE server
  • Server runtime facet enhancements (link TBD)
  • Migrate existing bundled server adapters to the remote server adapter support - our direction should be to have server providers host their own adapters as they

currently do for their runtimes. Server providers should also be encourage to use the remote server runtime installation framework (currently used by Geronimo)

SOA Tools Platform

The project did not provide any plan information.