Project Plan For Eclipse Web Tools Platform Project, version Mars

Introduction

The Web Tool Platform (WTP) project provides extensible frameworks and exemplary tools to build Web and Java EE applications. This document describes the features and the API set for the Mars release.

Release Deliverables

There will be SDK and non-SDK versions of each of the main deliverables:

  • XML IDE (including XSL, XSD, etc)
  • JSDT (JavaScript only)
  • Web Development (no Java technologies)
  • Java EE Development
  • OSGi Enterprise Development (incubating)
  • EPP Packaging project: The Eclipse IDE for Java EE Developers

Table of Contents

Release Milestones

WTP Milestones follow the Eclipse release milestones by an offset of 2 as set by the Mars release schedule. For details, see the WTP ramp down plan, Ramp down plan for WTP Mars.

Table of Contents

Target Environments

WTP will support the same platforms as the Eclipse Platform project. For a list of platforms supported in Mars, see Eclipse Target Operating Environments. That is, WTP is pure Java code, no native code, so should "run anywhere". WTP committers test primarily on Windows, some on Linux, and a little on Macs. Bugs reproducible only on other platforms will still be considered valid, but generally will require close adopter involvement to propose patches and test fixes.

WTP committers use and test on Java 6 and Java 7, but in theory should run on Java 5, as that is the highest version of Java assumed in the bundle's manifest.mf files (in the OSGi BREE heading), and, with few exceptions, our pre-reqs. Where there are exceptions, and Java 6 is required, such as for some JDT functions, everything else should continue to work fine just with reduced functionality. (Note, for committer convenience, some of the unit test bundles do assume Java 6.) Many of the WTP bundles assume only Java 4. The exact requirements can be determined by looking at the distributed bundles' BREE levels, but it is pretty much up to adopters to test or support Java 4 or Java 5 installations, if desired. If there are bugs only reproducible on Java 4 or Java 5, we will consider them valid, but generally give them a lower priority than other bugs.

Internationalization

Internationalization and Localization will be supported.

  • Internationalization (I18N)

    Each project should be able to work in an international environment, including support for operating in different locales and processing/displaying international data (dates, strings, etc.).

  • Localization

    Each project should provide an environment that supports the localization of the technology (i.e. translation). This includes, but is not limited to, ensuring that strings are externalized for easy translation.

  • We will provide "map files" or similar required input to the Babel Project, so they can deliver language packs translated into multiple languages in a timely manner. The primary languages to consider are: English, Simplified Chinese, Traditional Chinese, Japanese, French, German, Spanish.

Table of Contents

Compatibility with Previous Releases

In general, we in WTP strive to provide the same type of compatibility as the Eclipse Platform.

API compatibility. WTP 3.5 will be compatible with APIs declared in WTP 3.4, WTP 3.3 and WTP 3.2. See also WTP API Policy.

Workspace compatibility. A workspace being used with WTP 3.4, 3.3 or 3.2 should still open and work with WTP 3.5. In general, though, once a workspace is opened with WTP 3.5, there is no guarantee it will continue to work with older versions (that is, there may be some one-time migration of some workspace meta data that prevents it being usable in older versions.

Project compatibility. A project being used with WTP 3.2, 3.3 or 3.4 should still be capable of being imported into and work with WTP 3.5. In general, a project being used with WTP 3.N should be able to co-exist with using the project with 3.N-2 ... as long as no new function from 3.N is used. This use case is motivated by adopters supporting large development shops (say, of 20 to 100 developers) who can not all necessarily "move up" to latest version at the same time. They should all be able to normally share the same project, via SCMs and similar, until they all are able to move to common development version or until they use some new function in the latest release (which, of course, would not be present in the previous releases). Note, it is hard to completely guarantee this will always work since there is no "common API" or spec that says how to guarantee it. While we will make every effort to write good code that is "forward friendly" (such as, code that knows to ignore preferences or metadata that is not understood rather than blindly throwing an exception and failing or writing thousands of error messages to the log, we depend heavily on adopters reporting bugs they find in the many possible "co-existence scenarios". We'll consider bugs on this topic as valid and prioritize them along with other bugs. In cases where they can not be fixed, we will explicitly call out "co-existence" exceptions in our release or migrations documentation.

Table of Contents

Themes and Priorities

Themes and their priorities communicate the main objectives of the project and their importance. The section to follow defines themes that are common to all the sub-projects. Each sub-project defines additional themes and plan items corresponding to each of the themes.

Table of Contents

Appendix Sub-Project Plans

Sub-Project Plans:

Table of Contents

view raw xml of project plan
from project meta-data key "projectplanurl"