Draft Eclipse 3.0 Development Plan
Eclipse released draft version 3.0, which means that this best Open Source Java IDE will jump directly from version 2.0 to version 3.0. The release date of version 3.0 is scheduled to be in the second quarter of next year, in other words, it will be very likely to provide direct support for generic Java. In fact, in the current eclipse 3.0 plan, the planned Java new features will include generic, enumeration, automatic packing, enhanced For cycling, static import, metadata tools, and compiler API (JSR-199). If you are determined to join these new features, it means that the entire IDE will have a considerable change.
Other new features are almost all complementary. Still not seeing the emergence of the GUI design tool, which means that in the picture interface in Eclipse will continue to be a crime. Several new weights will appear in the reconstruction menu. Plug-in will be able to dynamically add ... and delete - huh, deleting plugins in Eclipse 2.1 is too inconvenient.
All in all, this is a version worth looking forward to. Unlike commercial software, each version of Open Source software is progressive, compatible (rather than sprouted new features) is placed in the first one. This is the truly trustworthy software. The following is part of the draft development plan, please see http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.html.
------------------
Eclipse ProjectDraft 3.0 Plan
Last Revised Thursday May 22, 2003 (Replace The Draft 2.2 Plan Of Dec. 20, 2002;
Marks Interesting Changes Since The Final 2.1 Plan) Please Send Comments About this Draft Plan to the Eclipse-dev@eclipse.org Developer Mailing List.
THIS Document Lays Out The Feature and API Set for the Next Feature Release Of Eclipse After 2.0 (Why Eclipse "3.0"?).
· Release DeliveRables
· Release Milestones
· Target Operating Environments
Compatibility with Previous Releases
· Eclipse Platform Subproject
· Java Development Tools (JDT) SubProject
· Plug-in Development Environment (PDE) SubProject
Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, we (the Eclipse PMC) post plans in an embryonic form and revise them throughout the release cycle.
The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change .The remainder of the plan consists of plan items for the various Eclipse subprojects. Each plan item covers a feature or API that is to be added to Eclipse, or some aspect of Eclipse that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail .
Not all plan items represent the same amount of work;. Some may be quite large, others, quite small Some plan items may involve work that is localized to a single Platform component; others may involve coordinated changes to several components; other may pervade the ........................
With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance, usability, etc. are considered routine ongoing maintenance activities and are not included in .
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 Worn't Be Aable To Address It. After Due Consideration, a Proposal Will Either Be Committed, Deferred, or Rejected.
· 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..
· Rejected plan item - Plan items that were proposed but judged unworkable are marked as rejected plan items, with an accompanying summary of why they were dismissed Keeping track of rejected items avoids repeating the discussion..
Release DeliveRables
The Release DeliveRables Have The Same Form As Previous Releases, Namely:
· Source Code Release for Eclipse Project, Availact, AvailacT, AVAILABLE As Versions Tagged "R3_0" in The Eclipse Project CVS Repository.
· Eclipse Project SDK (INCLUDES Platform, JDT, AND PDE Source Zips).
· Eclipse Platform Runtime Binary Distribution (Downloadable).
· JDT Runtime Binary Distribution (Downloadable).
· Eclipse SDK EXAMPLES (Downloadable).
· SWT Distribution (Downloadable).
Release Milestones
Release Milestone Occurring At Roughly 6 Week Interval To Facilitate Coarse-grained Planning and Staging. The Milestones for 2003 Are:
· Friday June 6, 2003 - MILESTONE 1 (3.0 m1) - Stable Build Reflecting Progress
Friday July 18, 2003 - Milestone 2 (3.0 m2) - Stable Build Reflecting Progress · Friday August 29, 2003 - Milestone 3 (3.0 m3) - Stable Build Reflecting Progress
Friday October 10, 2003 - Milestone 4 (3.0 m4) - Initial API Freeze - Stable Build Reflecting Progress
· Friday November 21, 2003 - Milestone 5 (3.0 M5) - APIS frozen - Stable Build Reflecting Progress
Additional 2004 milestones will be added later. Our target is to complete 3.0 in 2Q2004. 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 VERSIONS OF THE Underlying Operating Environments.
Most of the Eclipse SDK IS "Pure" JavaTM Code and Has No Direct Dependence on The underlying Operating System. The Chief Dependence is Therefore ON The Java 2 Platform Itself.
The 3.0 Release of The Eclipse Project Is Written and Compiled Against Version 1.4 of the Java 2 Platform Apis, and Targeted to Run On Version 1.4 of The Java 2 Runtime Environment, Standard Edition.
There are many different implementations of the Java 2 Platform running atop a variety of operating systems We focus Eclipse testing on a handful of popular combinations of operating system and Java 2 Platform;. These are our reference platforms Eclipse undoubtedly runs fine in many operating environments. beyond the reference platforms we test. However, since we do not systematically test them we can not vouch for them. Problems encountered when running Eclipse on non-reference platform that can not be recreated on any reference platform will be given lower priority than problems with running Eclipse ON A Reference Platform.eclipse SDK 3.0 IS Tested and Validated on The Following Reference Platforms (this List is Updated over the course of the release cycle):
Operating system
Processor Architecture
Window system
Java 2 Platform
Microsoft Windows XP
Intel x86
Win32
Sun Java 2 SDK, Standard Edition, Version 1.4.1_02 for Microsoft Windows
Microsoft Windows XP
Intel x86
Win32
IBM 32-Bit SDK for Windows, Java 2 Technology Edition, Version 1.4.0
Redhat linux 9 Professional
Intel x86
Gtk
Sun Java 2 SDK, Standard Edition, 1.4.1_02 for Linux X86
Redhat linux 9 Professional
Intel x86
Gtk
IBM Developer Kit for Linux, Java 2 Technology Edition, Version 1.4.0
SUSE Linux 8.2
Intel x86
Gtk
Sun Java 2 SDK, Standard Edition, 1.4.1_02 for Linux X86
SUSE Linux 8.2
Intel x86
Gtk
IBM Developer Kit for Linux, Java 2 Technology Edition, Version 1.4.0
Sun Solaris 8
Sparc
Motif
Sun Java 2 SDK, Standard Edition, 1.4.1_02 for Solaris SPARC
HP HP-UX 11i
HP9000PA-RISC
Motif
HP-UX SDK for the Java 2 Platform, Version 1.4.1.01 for HP9000 PA-RISC
IBM AIX 5.1
PowerPC
Motif
IBM Developer Kit for Aix, Java 2 Technology Edition, Version 1.4Apple Mac OS X 10.2
PowerPC
Carbon
Java 2 Standard Edition 1.4.1 for Mac OS X
Qnx Neutrino RTOS [Version TDB]
Intel x86
Photon
IBM J9 VM for QNX [Version TDB]
Internationalization 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.
Latin-1 locales are supported by the Eclipse SDK on all of the above operating environments; DBCS locales are supported by the Eclipse SDK on the Windows, GTK, and Motif window systems; BIDI locales are supported by the Eclipse SDK only on Windows operating environments .
The Eclipse SDK Supports GB 18030, The New Chinese Code Page Standard, on Windows XP and 2000, And Linux.
German and Japanese Locales Are Tested.
Bidi support
The Eclipse SDK is a development environment targeted at technical professionals - not an end user application However, the Eclipse SDK tools will permit technical professionals who are working in English to build Hebrew / Arabic end user Java programs which are themselves not based on the Eclipse. SDK. The BIDI support in the Eclipse SDK allows a Java programmer to work with BIDI strings, code comments, etc. but the Eclipse SDK itself is not designed to be localized for BIDI locales and its widget orientation can not be changed.
Important: The Above Bidi Support Is Available Only on Windows Platforms.
Compatibility with Previous Releases
Eclipse 3.0 Will NOT BE FULLY Compatible with Eclipse 2.0 and 2.1.
Compatibility Of Release 3.0 with 2.0 and 2.1
We have decided that the next release of Eclipse will not be fully compatible with 2.0 and 2.1. This gives us additional freedom to innovate and make the next Eclipse significantly better than it could have been had we tried to maintain compatibility. That said, most of the Eclipse APIs will be the same in 3.0 as in 2.1. We will only break APIs in 3.0 when have a compelling case for doing so. And when we find we need to break APIs, we would do it in a controlled way that minimizes the effort required to port an existing plug-in to the 3.0 APIs. We will provide a comprehensive Eclipse 3.0 Porting Guide that covers all areas of breaking API changes, and describes how to port existing 2.1 plug-ins to 3.0. Up-to-date drafts of the Eclipse 3.0 porting Guide will be included with milestone builds so that it's possible to climb aboard the 3.0 release wagon at the early stages, or to estimate the amount of effort that will be involved in eventually porting existing plug-ins to 3.0. API Contract Compatibility: Eclipse SDK 3.0 will be upwards contract-compatible with Eclipse SDK 2.0 and 2.1 except in those areas noted in the Eclipse 3.0 Porting Guide This means that programs in full compliance with contracts specified in Eclipse SDK 2.0 or 2.1 APIs will need to be. ported to Eclipse SDK 3.0 APIs. (API is construed broadly to include such things as plug-in extension points.) Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 3.0 APIs would ensure compliance with Eclipse SDK 2.0 or 2.1 Apis. REFER TO EVOLVING JAVA-BASED API A Discussion of The Kinds of Api Changes That Maintain Contract Compatibility.
Binary (plug-in) Compatibility:. Eclipse SDK 3.0 will not be upwards binary-compatible with Eclipse SDK 2.0 and 2.1 Plug-ins built for Eclipse SDK 2.0 or 2.1 will need to be ported and recompiled for Eclipse SDK 3.0 Downward plug-. in compatibility is not supported either Plug-ins for Eclipse SDK 3.0 will not be usable in Eclipse SDK 2.0 or 2.1 Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.Source Compatibility:.. Eclipse SDK 3.0 will be upwards source-compatible with Eclipse SDK 2.0 or 2.1 except in the areas noted in the Eclipse 3.0 Porting Guide. This means that source files written to use Eclipse SDK 2.0 or 2.1 APIs might successfully compile and run against Eclipse SDK 3.0 APIs Althought. Downward Source Compatibility IS Not Supported. If Source Files Use New Eclipse SDK APIS, They Will NOTB USABLE WIARLIER VERSION OF THE Eclipse SDK.
Workspace Compatibility: Eclipse SDK 3.0 will be upwards workspace-compatible with Eclipse SDK 2.0 or 2.1 unless noted This means that workspaces and projects created with Eclipse SDK 2.0 or 2.1 can be successfully opened by Eclipse SDK 3.0 and upgraded to a 3.0 workspace This.. includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project (eg, the .project file), which may propagate between workspaces via file copying or team repositories. Individual plug-ins developed for Eclipse SDK 3.0 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.0 plug-in developers are responsible for ensuring that their plug-ins recognize 3.0, 2.1, and 2.0 metadata and process it appropriately User interface session. State May Be Discarded WHEN A Workspace IS Upgraded. Downward Workspace Compatibility Is Not Supported. A Workspace Created (or OR Opened) by Eclips E SDK 3.0 Will Be Unusable with an Earlier Version of Eclipse SDK. Visible Metadata Files Created (or Overwritten) by Eclipse SDK 3.0 Will Generally Be Unusable with Earlier Versions of Eclipse SDK.
