development/plan/e4_plan_1_0.xml - gerrit/www.eclipse.org/e4 - Git at Google

 <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
 <!--  Use this to test local rendering in firefox -->
 <!-- <?xml-stylesheet type="text/xsl" href="project-plan-render.xsl"?> -->

 <?xml-stylesheet type="text/xsl" href="http://www.eclipse.org/projects/project-plan.xsl"?>

 <p:plan
   plan-format="1.0"
   xmlns:p="http://www.eclipse.org/project/plan" xmlns="http://www.w3.org/1999/xhtml"
   name="e4 Project">

 <p:release projectid="eclipse.e4" version="1.0"/>

 <!-- ============================================== -->

 <p:introduction>
 <div>

 <p>
 Last revised 15:00 ET February 12, 2010.
 </p>
 <p><i>Please send comments about this plan to the</i> <a href="mailto:e4-dev@eclipse.org">e4-dev@eclipse.org</a> <i>developer
   mailing list.</i>
 </p>
 <p>This draft document lays out the feature and API set for the next feature release
   of the Eclipse e4 project, designated release 1.0.
 </p>

 <p>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 e4 team) post plans in an embryonic form and revise them
   throughout the release cycle. </p>
 <p>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. </p>
 <p>The remainder of the plan consists of plan items for all of the component areas
   under the e4 Project. Each plan item covers a feature or API
   that is to be added to the e4 Project deliverables, or some aspect of
   the e4 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. </p>
 <p>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. Although some plan items are for work that
   is more pressing than others, the plan items appear in no particular order. </p>
 <p>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. </p>
 <p>The current status of each plan item is noted: </p>
 <ul>
   <li><b>Committed</b> plan item - A committed plan item is one that we have
     decided to address for the release.</li>
   <li><b>Proposed</b> 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.</li>
   <li><b>Deferred</b> 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.</li>
 </ul>

 </div>
 </p:introduction>

 <!-- ============================================== -->

 <p:release_deliverables>
 <div>

 <p>The complete set of release deliverables for the e4 project will include:</p>
 <ul>
   <li>Source code release for all e4 Project deliverables, available as
     versions tagged &quot;R1_0&quot; in the e4 Project <a href="http://dev.eclipse.org/viewcvs/">CVS
     repository</a>.</li>
   <li>e4 master zip (downloadable). Contains all source code, e4 bundles in binary form,
   and patches for applying portions of e4 onto an existing instance of the Eclipse Platform.</li>
   <li>A p2 repository of binary release deliverables, maintained in a public, stable location
   on the <a href="http://eclipse.org">http://eclipse.org</a> Web site.</li>
 </ul>

 </div>
 </p:release_deliverables>

 <!-- ============================================== -->

 <p:release_milestones>

 <p:preamble><p>
   Release milestones will be occurring at roughly 6 week intervals, and will generally occur
   three weeks after an Eclipse project milestone.
 </p>
 </p:preamble>

 <p:milestone date="10/09/2009" milestone="M1"><div>1.0M1</div></p:milestone>
 <p:milestone date="11/20/2009" milestone="M2"><div>1.0M2</div></p:milestone>
 <p:milestone date="01/15/2010" milestone="M3"><div>1.0M3</div></p:milestone>
 <p:milestone date="02/26/2010" milestone="M4"><div>1.0M4</div></p:milestone>
 <p:milestone date="04/09/2010" milestone="M5"><div>1.0M5</div></p:milestone>
 <p:milestone date="05/21/2010" milestone="M6"><div>1.0M6 (Feature and API Freeze)</div></p:milestone>

 <p:postamble>
 <div>
 <p>Our target is to complete 1.0 in late July 2010, one month after the Helios 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.</p>
 </div>
 </p:postamble>

 </p:release_milestones>

 <!-- ============================================== -->

 <p:target_environments>

 <div>
 <p>In order to remain current, each e4 Project release targets reasonably current
   operating environments.</p>
 <p>Most of the e4 Project is &quot;pure&quot; Java code and has no direct dependence
   on the underlying operating system. The chief dependence is therefore on the
   Java Platform itself. Portions 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.). In general, the 1.0 release of the e4 Project is developed on Java SE 5.</p>
 <p>e4 has dependencies on components from other Eclipse projects, notably the Platform
 project, and the EMF project. While specific version dependencies may specify
 a wider range, e4 is generally built and tested against the versions contained in the
 <a href="http://wiki.eclipse.org/Helios">Helios</a> release train.</p>
 <p>There are many different implementations of the Java Platform running atop
   a variety of operating systems. We focus our testing on a handful of
   popular combinations of operating system and Java Platform; these are our <em>reference
   platforms</em>. 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.</p>
 <p>e4 also has dependencies on browser technologies such as JavaScript. The
 reference platforms listed below show the versions of these technologies that we
 are developing and testing against.</p>
 <p>e4 1.0 is tested and validated on the following reference platforms
   (this list is updated over the course of the release cycle):</p>

 <style type="text/css">
 	table.platforms {
 		border-width: 1px;
 		border-spacing: 0px;
 		border-style: solid;
 		border-collapse: separate;
 	}
 	table.platforms th {
 		border-width: 1px;
 		padding: 3px;
 		border-style: inset;
 		border-color: black;
 		background-color: #B9A9FF;
 	}
 	table.platforms td {
 		border-width: 1px 1px 1px 1px;
 		padding: 3px 3px 3px 3px;
 		border-style: inset inset inset inset;
 		border-color: gray gray gray gray;
 	}
 	table.platforms tr.c0 td {
 		background-color: #FDFDFD;
 	}
 	table.platforms tr.c1 td {
 		background-color: #F4EEFF;
 	}
 </style>
 <center>
 	<table class="platforms">
 		<tr>
 			<th>Operating System</th>
 			<th>Version</th>
 			<th>Hardware</th>
 			<th>JRE</th>
 			<th>Windowing System</th>
 		</tr>
 		<!-- ************ WINDOWS ************** -->
 		<tr class="c0">
 			<td rowspan="2">Windows</td>
 			<td rowspan="1">7</td>
 			<td rowspan="2">x86 32-bit</td>
 			<td rowspan="2">Sun Java 5 Update 22<br/>
 				IBM Java 5 SR11
 			</td>
 			<td rowspan="2">Win32</td>
 		</tr>
 		<tr class="c0">
 			<td rowspan="1">XP</td>
 		</tr>
 		<!-- ************ RHEL ************** -->
 		<tr class="c1">
 			<td rowspan="1">Red Hat Enterprise Linux</td>
 			<td rowspan="1">5.0</td>
 			<td rowspan="1">x86 32-bit</td>
 			<td>	Sun Java 5 Update 22<br/>
 				IBM Java 5 SR11
 			</td>
 			<td rowspan="1">GTK</td>
 		</tr>
 		<!-- ************ Mac ************** -->
 		<tr class="c0">
 			<td rowspan="1">Apple Mac OS X</td>
 			<td rowspan="1">10.5</td>
 			<td rowspan="1">Universal</td>
 			<td rowspan="1">Apple Java 10.5 Update 2</td>
 			<td rowspan="1">Cocoa</td>
 		</tr>
 	</table>
  </center>
 <p>As stated above, <i>we expect that e4 works fine on other current
   Java VM and OS versions but we cannot flag these as reference platforms without
   significant community support for testing them.</i></p>
 </div>

 <p:internationalization>
 <p>The e4 platform is designed as the basis for internationalized products. The
   user interface elements provided by the e4 components, including dialogs
   and error messages, are externalized. The English strings are provided as the
   default resource bundles.</p>
 <p>Latin-1 and DBCS locales are supported by e4 on all reference platforms;
   BIDI locales are supported by e4 everywhere but on Motif.</p>
 <p>e4 supports GB 18030 (level 1), the Chinese code page standard,
   on Windows XP and 2000, Linux/GTK and the Macintosh.</p>
 </p:internationalization>

 </p:target_environments>

 <!-- ============================================== -->

 <p:compatibility_with_previous_releases>
 <div>

 <h3>Compatibility of e4 1.0 with previous Eclipse project releases</h3>
 <p>e4 1.0 will not be compatible with previous releases of e4, such as the e4 0.9 release.
 This includes binary compatibility, contract compatibility, workbench model compatibility,
 and workspace compatibility.
 </p>
 <p>
 e4 1.0 includes a set of bundles that are binary and API contract compatible with Eclipse Platform UI
 API from the Eclipse Helios (3.6) release. This set of bundles is known as the compatibility
 layer, and is intended to be used to create a full Eclipse SDK release on e4 that is fully
 compatible with previous Eclipse project releases. Thus while e4 1.0 itself is not
 compatible with previous Eclipse project releases, it provides the necessary
 infrastructure to allow a fully compatible e4-based release of the Eclipse SDK to be created.
 </p>

 <p><strong>Non-compliant usage of API's</strong>: All non-API methods and classes,
   and certainly everything in a package with &quot;internal&quot; 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 e4 API are inherently
   unsupportable and receive no guarantees about compatibility within a single
   release much less with earlier releases. Refer to
   <a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">
     <em>How to Use the Eclipse API</em>
   </a> for information about how to write compliant plug-ins. </p>

 </div>
 </p:compatibility_with_previous_releases>

 <!-- ============================================== -->

 <p:themes_and_priorities>

 <p:preamble>
 <div>
 <p>The plan items listed below were defined according to contributor requirements and the
   themes and priorities established by the e4 Project. Each plan item covers a feature or API that is
   to be added to the e4 Project deliverables, or some aspect of the e4 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 entails.</p>
 <p> Although there are several components under the e4 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. As such, this plan covers the work of all components
   under the e4 Project.</p>
 <p>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.
   See the corresponding bugzilla items for up-to-date status information on
   ongoing work and planned delivery milestones.</p>
 <p>The current status of each plan item is noted:</p>
 <ul>
   <li><b>Committed</b> plan item - A committed plan item is one that we have
     decided to address for the release. In bugzilla, this is reflected by
     having a concrete target milestone assigned.</li>
   <li><b>Proposed</b> 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. In bugzilla, such items are reflected
     by having a target milestone "1.0" assigned.</li>
   <li><b>Deferred</b> 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. In bugzilla, such items are reflected by having no
     target milestone assigned.</li>
 </ul>
 </div>
 </p:preamble>

 <!-- ============================================== -->

 <p:theme name="Easier to Develop">
 <p:description>
 <p>Over the years the Eclipse platform has accumulated a large body of API,
 resulting in a platform that is very powerful, but also very difficult for non-experts
 to use and extend. This theme encompasses work to make it easier to develop
 software components for the Eclipse platform.
 </p>
 </p:description>

 <p:committed>
   <p><i>None at this time.</i></p>
 </p:committed>

 <p:proposed>
 <ul>
 <li>
 <strong>Support for web UI components in the Eclipse platform</strong>
   There is growing demand for software components that can run both in
   traditional desktop environments, and Web browser environments. We will
   support this demand by providing first-class integration of web-based components
   in the Eclipse platform. In particular, we will support embedding of user interface components
   written in JavaScript into the e4 UI, and provide access to e4 API for JavaScript components.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302749">302749</a>)</li>

 <li>
 <strong>Support declarative and visual definition of user-interfaces.</strong>
   We will work with the community to identify and provide access to a best-of-breed
   declarative mechanism for defining widget-based user-interfaces in Eclipse. We
   will provide visual design tools to allow such user-interfaces to be crafted without
   requiring extensive programming knowledge.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302750">302750</a>)</li>

 <li>
 <strong>Eclipse application services.</strong>
   We will provide a new, simplified API for accessing basic Eclipse platform services.
   This will allow developers to create components for Eclipse by learning and using
   a much smaller set of API.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302751">302751</a>)</li>

 <li>
 <strong>Compatibility layer.</strong>
   Although the 1.0 release itself will not be backward compatible with earlier versions
   of the Eclipse platform, we will develop a compatibility layer that will allow the
   full Eclipse platform and all API-clean platform plug-ins to run without modification
   on e4.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302752">302752</a>)</li>
 </ul>
 </p:proposed>

 <p:deferred>
   <p><i>None at this time.</i></p>
 </p:deferred>

 </p:theme>

 <!-- ============================================== -->

 <p:theme name="Easier to Assemble">
 <p:description>
 <p>The Eclipse platform provides an excellent basis for producing extensible
 integrated development environments (IDEs). However, it can be difficult to
 assemble and customize Eclipse components into different kinds of applications
 or for different runtime environments. This theme encompasses work to
 make it easier to rearrange, customize, and otherwise mash up Eclipse components
 into very different kinds of applications.
 </p>
 </p:description>

 <p:committed>
   <p><i>None at this time.</i></p>
 </p:committed>

 <p:proposed>
 <ul>
 <li>
 <strong>Model-based workbench.</strong>
   The functionality of the Eclipse Workbench and IDE have grown significantly
   since they were created. In some cases, older capabilities have been superceded
   by newer ones or have been proven to be unwieldy or otherwise unsatisfying.
   We will create a new model of the underlying structure of the Eclipse UI, which
   will make development simpler, but more flexible and dynamic.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302753">302753</a>)</li>

 <li>
 <strong>Tools for application assembly.</strong>
   We will provide design tools to support assembling and laying out e4
   applications. This will allow authoring and customization of the application's
   model without requiring knowledge of the underlying programming and modelling
   technologies.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302754">302754</a>)</li>

 <li>
 <strong>Skinnable UI.</strong>
   We will enable developers to have greater control over the Eclipse UI,
   making it simple to customize the appearance of Eclipse-based applications
   using industry standard mechanisms such as CSS.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302755">302755</a>)</li>

 <li>
 <strong>OpenSocial Gadget container for Eclipse.</strong>
   We will provide a container for integrating OpenSocial gadgets into the Eclipse
   platform. This will allow rapid assembly and customization of applications by drawing
   from the large library of available OpenSocial gadgets.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302756">302756</a>)</li>

 <li>
 <strong>Service-oriented programming model.</strong>
   We will define and use a more service-oriented programming model for the e4 API.
   This will avoid use of singleton APIs and allow a greater variety of Eclipse platform capabilities to be
   interchanged, customized, reimplemented, or reused in other environments.
 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302757">302757</a>)</li>
 </ul>
 </p:proposed>

 <p:deferred>
   <p><i>None at this time.</i></p>
 </p:deferred>

 </p:theme>

 </p:themes_and_priorities>

 </p:plan>
	<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
	<!-- Use this to test local rendering in firefox -->
	<!-- <?xml-stylesheet type="text/xsl" href="project-plan-render.xsl"?> -->

	<?xml-stylesheet type="text/xsl" href="http://www.eclipse.org/projects/project-plan.xsl"?>

	<p:plan
	plan-format="1.0"
	xmlns:p="http://www.eclipse.org/project/plan" xmlns="http://www.w3.org/1999/xhtml"
	name="e4 Project">

	<p:release projectid="eclipse.e4" version="1.0"/>

	<!-- ============================================== -->

	<p:introduction>
	<div>

	<p>
	Last revised 15:00 ET February 12, 2010.
	</p>
	<p><i>Please send comments about this plan to the</i> <a href="mailto:e4-dev@eclipse.org">e4-dev@eclipse.org</a> <i>developer
	mailing list.</i>
	</p>
	<p>This draft document lays out the feature and API set for the next feature release
	of the Eclipse e4 project, designated release 1.0.
	</p>

	<p>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 e4 team) post plans in an embryonic form and revise them
	throughout the release cycle. </p>
	<p>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. </p>
	<p>The remainder of the plan consists of plan items for all of the component areas
	under the e4 Project. Each plan item covers a feature or API
	that is to be added to the e4 Project deliverables, or some aspect of
	the e4 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. </p>
	<p>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. Although some plan items are for work that
	is more pressing than others, the plan items appear in no particular order. </p>
	<p>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. </p>
	<p>The current status of each plan item is noted: </p>
	<ul>
	<li><b>Committed</b> plan item - A committed plan item is one that we have
	decided to address for the release.</li>
	<li><b>Proposed</b> 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.</li>
	<li><b>Deferred</b> 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.</li>
	</ul>

	</div>
	</p:introduction>

	<!-- ============================================== -->

	<p:release_deliverables>
	<div>

	<p>The complete set of release deliverables for the e4 project will include:</p>
	<ul>
	<li>Source code release for all e4 Project deliverables, available as
	versions tagged "R1_0" in the e4 Project <a href="http://dev.eclipse.org/viewcvs/">CVS
	repository</a>.</li>
	<li>e4 master zip (downloadable). Contains all source code, e4 bundles in binary form,
	and patches for applying portions of e4 onto an existing instance of the Eclipse Platform.</li>
	<li>A p2 repository of binary release deliverables, maintained in a public, stable location
	on the <a href="http://eclipse.org">http://eclipse.org</a> Web site.</li>
	</ul>

	</div>
	</p:release_deliverables>

	<!-- ============================================== -->

	<p:release_milestones>

	<p:preamble><p>
	Release milestones will be occurring at roughly 6 week intervals, and will generally occur
	three weeks after an Eclipse project milestone.
	</p>
	</p:preamble>

	<p:milestone date="10/09/2009" milestone="M1"><div>1.0M1</div></p:milestone>
	<p:milestone date="11/20/2009" milestone="M2"><div>1.0M2</div></p:milestone>
	<p:milestone date="01/15/2010" milestone="M3"><div>1.0M3</div></p:milestone>
	<p:milestone date="02/26/2010" milestone="M4"><div>1.0M4</div></p:milestone>
	<p:milestone date="04/09/2010" milestone="M5"><div>1.0M5</div></p:milestone>
	<p:milestone date="05/21/2010" milestone="M6"><div>1.0M6 (Feature and API Freeze)</div></p:milestone>

	<p:postamble>
	<div>
	<p>Our target is to complete 1.0 in late July 2010, one month after the Helios 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.</p>
	</div>
	</p:postamble>

	</p:release_milestones>

	<!-- ============================================== -->

	<p:target_environments>

	<div>
	<p>In order to remain current, each e4 Project release targets reasonably current
	operating environments.</p>
	<p>Most of the e4 Project 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 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.). In general, the 1.0 release of the e4 Project is developed on Java SE 5.</p>
	<p>e4 has dependencies on components from other Eclipse projects, notably the Platform
	project, and the EMF project. While specific version dependencies may specify
	a wider range, e4 is generally built and tested against the versions contained in the
	<a href="http://wiki.eclipse.org/Helios">Helios</a> release train.</p>
	<p>There are many different implementations of the Java Platform running atop
	a variety of operating systems. We focus our testing on a handful of
	popular combinations of operating system and Java Platform; these are our <em>reference
	platforms</em>. 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.</p>
	<p>e4 also has dependencies on browser technologies such as JavaScript. The
	reference platforms listed below show the versions of these technologies that we
	are developing and testing against.</p>
	<p>e4 1.0 is tested and validated on the following reference platforms
	(this list is updated over the course of the release cycle):</p>

	<style type="text/css">
	table.platforms {
	border-width: 1px;
	border-spacing: 0px;
	border-style: solid;
	border-collapse: separate;
	}
	table.platforms th {
	border-width: 1px;
	padding: 3px;
	border-style: inset;
	border-color: black;
	background-color: #B9A9FF;
	}
	table.platforms td {
	border-width: 1px 1px 1px 1px;
	padding: 3px 3px 3px 3px;
	border-style: inset inset inset inset;
	border-color: gray gray gray gray;
	}
	table.platforms tr.c0 td {
	background-color: #FDFDFD;
	}
	table.platforms tr.c1 td {
	background-color: #F4EEFF;
	}
	</style>
	<center>
	<table class="platforms">
	<tr>
	<th>Operating System</th>
	<th>Version</th>
	<th>Hardware</th>
	<th>JRE</th>
	<th>Windowing System</th>
	</tr>
	<!-- ********** WINDOWS ************ -->
	<tr class="c0">
	<td rowspan="2">Windows</td>
	<td rowspan="1">7</td>
	<td rowspan="2">x86 32-bit</td>
	<td rowspan="2">Sun Java 5 Update 22<br/>
	IBM Java 5 SR11
	</td>
	<td rowspan="2">Win32</td>
	</tr>
	<tr class="c0">
	<td rowspan="1">XP</td>
	</tr>
	<!-- ********** RHEL ************ -->
	<tr class="c1">
	<td rowspan="1">Red Hat Enterprise Linux</td>
	<td rowspan="1">5.0</td>
	<td rowspan="1">x86 32-bit</td>
	<td> Sun Java 5 Update 22<br/>
	IBM Java 5 SR11
	</td>
	<td rowspan="1">GTK</td>
	</tr>
	<!-- ********** Mac ************ -->
	<tr class="c0">
	<td rowspan="1">Apple Mac OS X</td>
	<td rowspan="1">10.5</td>
	<td rowspan="1">Universal</td>
	<td rowspan="1">Apple Java 10.5 Update 2</td>
	<td rowspan="1">Cocoa</td>
	</tr>
	</table>
	</center>
	<p>As stated above, <i>we expect that e4 works fine on other current
	Java VM and OS versions but we cannot flag these as reference platforms without
	significant community support for testing them.</i></p>
	</div>

	<p:internationalization>
	<p>The e4 platform is designed as the basis for internationalized products. The
	user interface elements provided by the e4 components, including dialogs
	and error messages, are externalized. The English strings are provided as the
	default resource bundles.</p>
	<p>Latin-1 and DBCS locales are supported by e4 on all reference platforms;
	BIDI locales are supported by e4 everywhere but on Motif.</p>
	<p>e4 supports GB 18030 (level 1), the Chinese code page standard,
	on Windows XP and 2000, Linux/GTK and the Macintosh.</p>
	</p:internationalization>

	</p:target_environments>

	<!-- ============================================== -->

	<p:compatibility_with_previous_releases>
	<div>

	<h3>Compatibility of e4 1.0 with previous Eclipse project releases</h3>
	<p>e4 1.0 will not be compatible with previous releases of e4, such as the e4 0.9 release.
	This includes binary compatibility, contract compatibility, workbench model compatibility,
	and workspace compatibility.
	</p>
	<p>
	e4 1.0 includes a set of bundles that are binary and API contract compatible with Eclipse Platform UI
	API from the Eclipse Helios (3.6) release. This set of bundles is known as the compatibility
	layer, and is intended to be used to create a full Eclipse SDK release on e4 that is fully
	compatible with previous Eclipse project releases. Thus while e4 1.0 itself is not
	compatible with previous Eclipse project releases, it provides the necessary
	infrastructure to allow a fully compatible e4-based release of the Eclipse SDK to be created.
	</p>

	<p><strong>Non-compliant usage of API's</strong>: 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 e4 API are inherently
	unsupportable and receive no guarantees about compatibility within a single
	release much less with earlier releases. Refer to
	<a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">
	<em>How to Use the Eclipse API</em>
	</a> for information about how to write compliant plug-ins. </p>

	</div>
	</p:compatibility_with_previous_releases>

	<!-- ============================================== -->

	<p:themes_and_priorities>

	<p:preamble>
	<div>
	<p>The plan items listed below were defined according to contributor requirements and the
	themes and priorities established by the e4 Project. Each plan item covers a feature or API that is
	to be added to the e4 Project deliverables, or some aspect of the e4 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 entails.</p>
	<p> Although there are several components under the e4 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. As such, this plan covers the work of all components
	under the e4 Project.</p>
	<p>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.
	See the corresponding bugzilla items for up-to-date status information on
	ongoing work and planned delivery milestones.</p>
	<p>The current status of each plan item is noted:</p>
	<ul>
	<li><b>Committed</b> plan item - A committed plan item is one that we have
	decided to address for the release. In bugzilla, this is reflected by
	having a concrete target milestone assigned.</li>
	<li><b>Proposed</b> 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. In bugzilla, such items are reflected
	by having a target milestone "1.0" assigned.</li>
	<li><b>Deferred</b> 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. In bugzilla, such items are reflected by having no
	target milestone assigned.</li>
	</ul>
	</div>
	</p:preamble>

	<!-- ============================================== -->

	<p:theme name="Easier to Develop">
	<p:description>
	<p>Over the years the Eclipse platform has accumulated a large body of API,
	resulting in a platform that is very powerful, but also very difficult for non-experts
	to use and extend. This theme encompasses work to make it easier to develop
	software components for the Eclipse platform.
	</p>
	</p:description>

	<p:committed>
	<p><i>None at this time.</i></p>
	</p:committed>

	<p:proposed>
	<ul>
	<li>
	<strong>Support for web UI components in the Eclipse platform</strong>
	There is growing demand for software components that can run both in
	traditional desktop environments, and Web browser environments. We will
	support this demand by providing first-class integration of web-based components
	in the Eclipse platform. In particular, we will support embedding of user interface components
	written in JavaScript into the e4 UI, and provide access to e4 API for JavaScript components.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302749">302749</a>)</li>

	<li>
	<strong>Support declarative and visual definition of user-interfaces.</strong>
	We will work with the community to identify and provide access to a best-of-breed
	declarative mechanism for defining widget-based user-interfaces in Eclipse. We
	will provide visual design tools to allow such user-interfaces to be crafted without
	requiring extensive programming knowledge.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302750">302750</a>)</li>

	<li>
	<strong>Eclipse application services.</strong>
	We will provide a new, simplified API for accessing basic Eclipse platform services.
	This will allow developers to create components for Eclipse by learning and using
	a much smaller set of API.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302751">302751</a>)</li>

	<li>
	<strong>Compatibility layer.</strong>
	Although the 1.0 release itself will not be backward compatible with earlier versions
	of the Eclipse platform, we will develop a compatibility layer that will allow the
	full Eclipse platform and all API-clean platform plug-ins to run without modification
	on e4.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302752">302752</a>)</li>
	</ul>
	</p:proposed>

	<p:deferred>
	<p><i>None at this time.</i></p>
	</p:deferred>

	</p:theme>

	<!-- ============================================== -->

	<p:theme name="Easier to Assemble">
	<p:description>
	<p>The Eclipse platform provides an excellent basis for producing extensible
	integrated development environments (IDEs). However, it can be difficult to
	assemble and customize Eclipse components into different kinds of applications
	or for different runtime environments. This theme encompasses work to
	make it easier to rearrange, customize, and otherwise mash up Eclipse components
	into very different kinds of applications.
	</p>
	</p:description>

	<p:committed>
	<p><i>None at this time.</i></p>
	</p:committed>

	<p:proposed>
	<ul>
	<li>
	<strong>Model-based workbench.</strong>
	The functionality of the Eclipse Workbench and IDE have grown significantly
	since they were created. In some cases, older capabilities have been superceded
	by newer ones or have been proven to be unwieldy or otherwise unsatisfying.
	We will create a new model of the underlying structure of the Eclipse UI, which
	will make development simpler, but more flexible and dynamic.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302753">302753</a>)</li>

	<li>
	<strong>Tools for application assembly.</strong>
	We will provide design tools to support assembling and laying out e4
	applications. This will allow authoring and customization of the application's
	model without requiring knowledge of the underlying programming and modelling
	technologies.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302754">302754</a>)</li>

	<li>
	<strong>Skinnable UI.</strong>
	We will enable developers to have greater control over the Eclipse UI,
	making it simple to customize the appearance of Eclipse-based applications
	using industry standard mechanisms such as CSS.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302755">302755</a>)</li>

	<li>
	<strong>OpenSocial Gadget container for Eclipse.</strong>
	We will provide a container for integrating OpenSocial gadgets into the Eclipse
	platform. This will allow rapid assembly and customization of applications by drawing
	from the large library of available OpenSocial gadgets.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302756">302756</a>)</li>

	<li>
	<strong>Service-oriented programming model.</strong>
	We will define and use a more service-oriented programming model for the e4 API.
	This will avoid use of singleton APIs and allow a greater variety of Eclipse platform capabilities to be
	interchanged, customized, reimplemented, or reused in other environments.
	(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=302757">302757</a>)</li>
	</ul>
	</p:proposed>

	<p:deferred>
	<p><i>None at this time.</i></p>
	</p:deferred>

	</p:theme>

	</p:themes_and_priorities>

	</p:plan>