Skip to main content
Location: /localsite//webtools/standard-project-plans/mars/wtp-plan.xml
Meta-data Tag: projectplanurl

	<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<!-- Use this to test local rendering in firefox -->

<?xml-stylesheet type="text/xsl" href=""?>
<!-- <?xml-stylesheet type="text/xsl" href=""?> -->
    name="Web Tools Platform">
        <p>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.
            There will be SDK and non-SDK versions of each of the main
                <li>XML IDE (including XSL, XSD, etc)</li>
                <li>JSDT (JavaScript only)</li>
                <li>Web Development (no Java technologies)</li>
                <li>Java EE Development</li>
                <li>OSGi Enterprise Development (incubating)</li>
                <li>EPP Packaging project: The Eclipse IDE for Java EE
                WTP Milestones follow the Eclipse release milestones by
                an offset of 2 as set by the
                <a href="">Mars release schedule.</a>
                For details, see the WTP  ramp down plan,
                <a href="">Ramp down plan for WTP Mars.</a>
            WTP will support the same platforms as the Eclipse
            Platform project. For a list of platforms supported in
            Mars, see
            <a href="">Eclipse Target Operating Environments</a>.
            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 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 and Localization will be supported.
                        Internationalization (I18N)
                        <p>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.).
                        <p>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
                        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,
                        Chinese, Traditional Chinese, Japanese, French,
                        German, Spanish.
                In general, we in WTP strive to provide the same type of
                <a href="">compatibility as the Eclipse Platform</a>.</p>
                <p><strong>API compatibility.</strong> WTP 3.5 will be compatible with APIs declared in WTP 3.4, WTP 3.3 and WTP 3.2. See also <a href="">WTP API Policy</a>.</p>
                <p><strong>Workspace compatibility.</strong>
                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.</p>
                <p><strong>Project compatibility.</strong>
                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. 
            <p> 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
    <p:appendix name="Sub-Project Plans">
            Sub-Project Plans:
                    <a href="">WTP Common Tools</a>
                    <a href="">Dali Java Persistence Tools</a>
                    <a href="">Enterprise Tools for the OSGi Service Platform</a>
                    <a href="">Java EE Tools</a>
                    <a href="">JavaScript Development Tools</a>
                    <a href="">JSF Tools</a>
                    <a href="">Server Tools</a>
                    <a href="">Source Editing</a>
                    <a href="">Web Services</a>
                    <a href="">WTP Releng</a>

Back to the top