This document lays out the feature and API set for the next feature release of the Eclipse Visual Editor Project after version 1.0, designated release version 1.1.
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 Tools/Visual Editor Project subproject. 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.
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 release deliverables are:
Release milestone occurring at roughly 6 week intervals exist to facilitate coarse-grained planning and staging. The milestones are:
The 1.1 release is targeted for 2Q2005. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.
In order to remain current, each 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" Java™ 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 Visual Editor Project version 1.1 release depends on the following:
The 1.1 release of Visual Editor Project 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.
Visual Editor Project 1.1 is tested and validated on the following reference platforms:
|
Eclipse Reference Platforms
|
|||
|---|---|---|---|
| Operating system | Processor architecture | Window system | Java 2 Platform |
| Red Hat Enterprise Linux WS 3 | Intel x86 | GTK | Sun Java 2 Standard Edition, 1.4.2_03 for Linux x86 |
| Microsoft Windows XP |
Intel x86 | Win32 |
Sun Java 2 Standard Edition, version 1.4.2_04 for Microsoft Windows |
[See the Eclipse Project 3.1 plan for a list of reference platforms.]
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 Visual Editor Project 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.
[Compatible evolution is the basis for long-lived software, and the norm for all Eclipse projects. The following boilerplate spells this out. In exception circumstances, a project may need to deviate from the norm. If that is the case, it is critical that this section explains how and why this project differs from the norm of compatibility.]
Eclipse Visual Editor Project 1.1 will be compatible with Visual Editor Project 1.0.
API Contract Compatibility: Visual Editor Project 1.0 defines all API contracts as internal APIs. A major plan item for Visual Editor Project 1.1 will be to begin defining what is and is not API (see below).
Source and Binary (plug-in) Compatibility:
Because Visual Editor Project 1.0 did not define any public API, by
definition, no binary compatibility is enabled. However, we
will work with all add-in providers to help them migrate their code to
the new officially-supported APIs.
Visual Editor Layout Compatibility:
Eclipse Visual Editor Project 1.1 will be able to read and operate on
all Java source code that is created using Visual Editor Project 1.0.
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.
Each theme has a number of items; the relevant theme is identified for each committed, proposed, and deferred plan items.
The current status of each plan item is noted:
The Eclipse Visual Editor Project intends to become the GUI editor for any language that can be used inside Eclipse. Plan items reflect new features of the Visual Editor Project, or areas where existing features will be significantly reworked.
Platform Performance. Put simply, VEP can be faster. We intend to do whatever rewriting and refactoring is necessary in order to make the experience of using VEP as pleasant and usable as possible from a performance perspective. This includes opening a new visual editor after the VEP plugin has already been activated and updating the visual design surface whenever the programmer changes the source code. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=77674)
API documentation. Currently, all Visual Editor Project APIs are internal APIs. We will begin the process of solidifying and documenting APIs. This work depends on the Platform Performance work, because some of the performance optimizations we consider may have the effect of breaking our current (internal) APIs. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=77677)
Evolve Rich Client Platform Support. Currently, Eclipse's Rich Client Platform is supported by VEP's ability to edit an arbitrary Composite. It would be nicer to have more complete integration. For example, it would be nice to be able to create an Eclipse View or Editor from VEP's File/New wizard. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=77679)
Object factory support / JFace support. JFace has taken the lead by creating SWT layouts using a
public Composite createPartControl(Composite parent);
factory method pattern. Essential Data and other frameworks have copied this good idea and used it in many places. We need to support this. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=77682)
Support Eclipse's FormLayout and JGoodies FormLayout layout managers. One of the first things we would like to document is how to extend VEP to support custom layout managers. Subject to time constraints, we will implement one or both of these layout managers in VEP and document how we did it to assist with future layout manager integration efforts.
It is extremely likely that the implementation of both layout managers will be contingent on receiving adequate volunteer assistance from the Visual Editor Project open-source development community. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=77683)
MacOS/X Support. Quite a few people want first-class support for MacOS. Implementation of this plan item is contingent on receiving adequate volunteer assistance from the community.
The following items have been proposed on the Visual Editor Project newsgroup. They are listed here so that we do not lose them (and are not listed in any particular order). Note that although all of these items are listed as deferred, if the Visual Editor Project team receives enough help from the community, these items can be added to the "committed items" or "completed items" list.
Eclipse Forms toolkit support. Some RCP projects are using the Eclipse Forms toolkit.
More coding pattern support. So you can bring your JBuilder project, NetBeans project, etc., into VE.
Palette customization. The ablility to add, move and delete items/categories from the palette.
Cut/Copy/paste controls on the design surface.
Java 1.4 and 1.5 support. JSpinner, SpringLayout, etc.
Support Custom Swing models. Table models, etc.
BeanInfo editor. Writing custom BeanInfo can be tedious. This is an opportunity for automation.
Support for custom Swing Action creation. Swing objects that generate actions should be able to generate custom actions.