Google Git
Sign in
eclipse / www.eclipse.org / eclipse / 936fe1b09237dda8457b8e04fcb028fbd0618bea / . / development / eclipse_project_plan_2_1_20030221.html
blob: 201daa4143f8b5d3e86fb0113c15d560b352d5d3 [file] [log] [blame]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="Author" content="Eclipse Project PMC">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Eclipse Project Draft 2.1 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>
<h1>
Eclipse Project<br>
DRAFT 2.1 Plan</h1>
<p>Last revised Friday, February 21, 2003 (<img border="0" src="new.gif" width="12" height="12">
marks interesting changes since the <a href="eclipse_project_plan_2_1_20030129.html">previous
draft of Jan. 29, 2003</a>)<br>
<br>
<i>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to the </i><a href="mailto:eclipse-dev@eclipse.org">eclipse-dev@eclipse.org</a>
<i>developer mailing list.</i> </p>
<p>This document lays out the feature and API set for the next feature release
of Eclipse, designated release 2.1.
<p>Plans do not materialize out of nowhere, nor are they entirely static. To make
the planning process more transparent and open to the Eclipse community, we
(the Eclipse PMC) posted the plan in an embryonic form and are revising
it throughout the release cycle.
<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.&nbsp;<p>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
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
details (which can be hashed out elsewhere).&nbsp;
<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 Platform component; others may involve coordinated changes to several
components; other may pervade the entire Platform.
<p>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, 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. All interesting
feature work is accounted for in this plan.
<p>The current status of each plan item is
noted:
<ul>
<li><b>Proposed</b> plan item - A proposal for an aspect to work on for the
release. After due consideration, a proposal will either be committed,
rejected, or deferred.</li>
<li><b>Committed</b> plan item - A committed plan item is one that we have decided
to address for the release.</li>
<li><b>Deferred</b> plan item - A reasonable proposal that did not make it in
to this release for some reason is marked as deferred with a brief note as
to why they were deferred. Deferred plan items may resurface as proposed plan
items at a later point.</li>
<li><b>Rejected</b> 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.</li>
</ul>
<h2>Release deliverables</h2>
<p>The release deliverables have the same form as previous releases, namely:
<ul>
<li>Source code release for Eclipse Project, available as versions tagged &quot;R2_1&quot;
in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS repository</a>.</li>
<li>Eclipse Project SDK (includes Platform, JDT, and PDE source zips)
(downloadable).</li>
<li>Eclipse Platform runtime binary distribution (downloadable).</li>
<li>JDT runtime binary distribution (downloadable).</li>
<li>Eclipse SDK Examples (downloadable).</li>
</ul>
<h2><a name="Milestones"></a>Release milestones</h2>
<p>Release milestone occurring at roughly monthly intervals exist to facilitate
coarse-grained planning and staging. The milestones for this release are:</p>
<ul>
<li>September 20, 2002 - Milestone 1 - (2.1 M1) - stable build reflecting progress</li>
<li>October 18, 2002 - Milestone 2 - (2.1 M2) - stable build reflecting progress</li>
<li>November 15, 2002 - Milestone 3 - (2.1 M3) - stable build reflecting
progress</li>
<li>December 13, 2002 [delayed to December 18] - Milestone 4 - (2.1 M4) - stable
build reflecting progress</li>
<li>February 7,&nbsp;2003 - Milestone 5 - (2.1 M5) - stable build - feature
complete - development freeze</li>
</ul>
<p>Lock down and testing then begins with M5, and progress through a series of
test-fix passes against candidates releases. Release candidate builds are planned
as follows (M5 is release candidate 0):</p>
<ul>
<li>Friday February 21, 2003 - Release Candidate 1 - (2.1 RC1)</li>
<li>Friday March 7, 2003 - Release Candidate 2 - (2.1 RC2)</li>
<li>Friday March 14, 2003 - Release Candidate 3 - (2.1 RC3)</li>
</ul>
<p> Depending on the circumstances, we may add additional release candidate builds
or fine-tune the schedule. The 2.1 release is targeted for Friday March 28,
2003. See the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-project-home/plans/freeze_plan_2_1.html">Eclipse
2.1 Endgame Plan</a> for further details. 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>
<h2>Target Operating Environments</h2>
<p>In order to remain current, each Eclipse release targets reasonably current
versions of the underlying operating environments.</p>
<p>Most of the Eclipse SDK is &quot;pure&quot; Java&trade; code and has no direct
dependence on the underlying operating system. The chief dependence is therefore
on the Java 2 Platform itself. The 2.1 release of the Eclipse Project is written
and compiled against version 1.3 of the Java 2 Platform APIs, and targeted to
run on either version 1.3 or 1.4 of the Java 2 Runtime Environment, Standard
Edition.</p>
<p>Eclipse SDK 2.1 will be tested and validated on the following Java 2
Platform implementations:</p>
<table width="91%" border="1">
<tbody>
<tr>
<td width="21%"><b>Operating system</b></td>
<td width="18%"><b>Processor architecture</b></td>
<td width="73%"><b>Java 2 Platforms</b></td>
</tr>
<tr>
<td width="21%" rowSpan="4">Microsoft®<br>
Windows®</td>
<td width="18%" rowSpan="4">Intel x86</td>
<td width="73%"> Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for
Microsoft Windows</td>
</tr>
<tr>
<td width="73%"> Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for
Microsoft Windows</td>
</tr>
<tr>
<td width="73%"> <img border="0" src="new.gif" width="12" height="12"> IBM
Developer Kit for Windows, Java 2 Technology Edition, version 1.3.1 SR-2
(pending fix to VM defect uncovered in SR-3)</td>
</tr>
<tr>
<td width="73%"> IBM 32-bit SDK for Windows, Java 2 Technology Edition,
version 1.4.0</td>
</tr>
<tr>
<td width="21%" rowSpan="3">Linux</td>
<td width="18%" rowSpan="3">Intel x86</td>
<td width="73%"> Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for
Linux x86</td>
</tr>
<tr>
<td width="73%"> Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for
Linux x86</td>
</tr>
<tr>
<td width="73%"> <img border="0" src="new.gif" width="12" height="12"> IBM
Developer Kit for Linux, Java 2 Technology Edition, version 1.3.1 SR-2
(pending fix to VM defect uncovered in SR-3)</td>
</tr>
<tr>
<td width="21%" rowSpan="2">Sun Solaris</td>
<td width="18%" rowSpan="2">SPARC</td>
<td width="73%"> Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for
Solaris SPARC</td>
</tr>
<tr>
<td width="73%"> Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for
Solaris SPARC</td>
</tr>
<tr>
<td width="21%">HP HP-UX</td>
<td width="18%">hp9000 PA-RISC</td>
<td width="73%"><span class="header">HP-UX SDK for the Java 2 platform,
version 1.3.1 for hp9000 PA-RISC</span></td>
</tr>
<tr>
<td width="21%">IBM® AIX</td>
<td width="18%">PowerPC</td>
<td width="73%"> IBM Developer Kit for AIX, Java 2 Technology Edition, version
1.3.1</td>
</tr>
<tr>
<td width="21%" rowSpan="2">Apple® Mac® OS</td>
<td width="18%" rowSpan="2">PowerPC</td>
<td width="73%">Java 2 Standard Edition 1.3.1 for Mac OS X 10.2</td>
</tr>
<tr>
<td width="73%">Java 2 Standard Edition 1.4.1 for Mac OS X 10.2 (pre-release)</td>
</tr>
<tr>
<td width="21%"><span class="title">QNX</span>®<span class="title"> Neutrino</span>®<span class="title">
RTOS</span></td>
<td width="18%">Intel x86</td>
<td width="73%">IBM J9 VM for QNX, version 2.0</td>
</tr>
</tbody>
</table>
<p><span class="header">The following table describes the combinations of
operating system and Java 2 Platform used when testing the Eclipse SDK
configurations. The status column indicates the level of testing:
&quot;Primary&quot; means a full tested configuration; &quot;</span>Secondary&quot;
means a configuration which is only lightly tested; &quot;Untested&quot; means a
configuration that has received no testing, but which should work.</p>
<table width="91%" border="1" height="415">
<tbody>
<tr>
<td width="11%" height="32"><b>Window system</b></td>
<td width="28%" height="32"><b>Java 2 Platform<br>
(see above table)</b></td>
<td width="42%" height="32"><b>Operating Environment</b></td>
<td width="19%" height="32"><b>Testing Status</b></td>
</tr>
<tr>
<td width="11%" rowSpan="5" height="104">Win32</td>
<td width="28%" rowSpan="5" height="104">Windows on Intel x86</td>
<td width="42%" height="16">Windows XP</td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="42%" height="16">Windows 2000</td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="42%" height="16">Windows ME</td>
<td width="19%" height="16">Secondary</td>
</tr>
<tr>
<td width="42%" height="16">Windows 98SE</td>
<td width="19%" height="16">Secondary</td>
</tr>
<tr>
<td width="42%" height="16">Windows NT</td>
<td width="19%" height="16">Secondary</td>
</tr>
<tr>
<td width="11%" rowSpan="6" height="152">Motif</td>
<td width="28%" rowSpan="3" height="86">&nbsp; <p>Linux on Intel x86</p>
<p>&nbsp;</p></td>
<td width="42%" height="25">RedHat Linux 8.0 x86</td>
<td width="19%" height="25">Primary</td>
</tr>
<tr>
<td width="42%" height="25">SuSE Linux 8.1 x86</td>
<td width="19%" height="25">Primary</td>
</tr>
<tr>
<td width="42%" height="24">Other Linux; kernel version 2.4.7, and XFree86
version 4.1.0</td>
<td width="19%" height="24">Untested</td>
</tr>
<tr>
<td width="28%" height="16">Solaris on SPARC&nbsp;</td>
<td width="42%" height="16">Sun Solaris 8 SPARC</td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="28%" height="16">HP-UX on hp9000 PA-RISC</td>
<td width="42%" height="16">HP-UX 11i hp9000</td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="28%" height="16">AIX on PowerPC</td>
<td width="42%" height="16">IBM AIX 5.1 on PowerPC</td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="11%" rowSpan="4" height="81">GTK</td>
<td width="28%" rowSpan="4" height="81">Linux on Intel x86</td>
</tr>
<tr>
<td height="15">RedHat Linux 8.0 x86 (<img border="0" src="new.gif" width="12" height="12">
GTK 2.2 required for DBCS)</td>
<td height="15">Primary</td>
</tr>
<tr>
<td width="42%" height="16">SuSE Linux 8.1 x86 (<img border="0" src="new.gif" width="12" height="12">
GTK 2.2 required for DBCS)</td>
<td width="19%" height="16">Primary</td>
</tr>
<tr>
<td width="42%" height="16">Other Linux; GTK 2.0.6 (<img border="0" src="new.gif" width="12" height="12">
GTK 2.2 required for DBCS)</td>
<td width="19%" height="16">Untested</td>
</tr>
<tr>
<td width="11%" height="16">Carbon</td>
<td width="28%" height="16">Mac OS X on PowerPC</td>
<td width="42%" height="16">Mac OS X 10.2</td>
<td width="19%" height="16"><i>Early access</i></td>
</tr>
<tr>
<td width="11%" height="16">Photon®</td>
<td width="28%" height="16">IBM J9 VM for QNX</td>
<td width="42%" height="16">QNX Neutrino RTOS 6.2.1&nbsp;</td>
<td width="19%" height="16">Primary</td>
</tr>
</tbody>
</table>
<h4>Internationalization</h4>
<p>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.</p>
<p>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.
<p>The Eclipse SDK supports GB 18030, the new Chinese code page standard, on Windows
XP and 2000, and <img border="0" src="new.gif" width="12" height="12"> Linux.
Note, however, that GB 18030 also requires locale and character encoding support
from the Java 2 Runtime Environment; this support is standard in version 1.4,
and also available in some 1.3 JREs.
<p> German and Japanese locales have been tested.
<h4>BIDI support</h4>
<p>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.</p>
<p><i>IMPORTANT: The above BIDI support is available only on Windows platforms.</i></p>
<h2>
Compatibility with Previous Releases</h2>
<p>
It is a given that Eclipse 2.1 will be upwards compatible with Eclipse 2.0. An incompatible break with the past this early on would be both unwelcome and
unwarranted.</p>
<h3>
Compatibility of Release 2.1 with 2.0</h3>
Eclipse SDK 2.1 will be upwards compatible with Eclipse SDK 2.0 to the
greatest extent possible. We anticipate a small number of areas where slavishly
maintaining compatibility would not be in the best interests of the Platform or
its clients. All such exceptions will be noted in the 2.1 release notes so that
clients can assess the impact of these changes on their plug-ins and products.
<p><b>API Contract Compatibility:</b> Eclipse SDK 2.1 will be upwards contract-compatible
with Eclipse SDK 2.0 unless noted. This means that programs in full compliance
with contracts specified in Eclipse SDK 2.0 APIs will automatically be in full
compliance with Eclipse SDK 2.1 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 2.1 APIs would
ensure compliance with Eclipse SDK 2.0 APIs. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain
contract compatibility.
<p><b>Binary (plug-in) Compatibility:</b> Eclipse SDK 2.1 will be upwards binary-compatible
with Eclipse SDK 2.0 unless noted. This means that plug-ins built for Eclipse
SDK 2.0 will continue to work correctly in Eclipse SDK 2.1 without change. Downward
plug-in compatibility is not supported. Plug-ins for Eclipse SDK 2.1 are unlikely
to be usable in Eclipse SDK 2.0. Plug-ins with hard-coded references in their
plug-in manifest file to 2.0 versions of prerequisite Eclipse Project plug-ins
will work in 2.1 provided the version match rule is &quot;greaterOrEqual&quot;
or &quot;compatible&quot; (the default); references using &quot;perfect&quot;
or &quot;equivalent&quot; match rules will be broken. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain
binary compatibility.
<p><b>Source Compatibility:</b> Eclipse SDK 2.1 will be upwards source-compatible
with Eclipse SDK 2.0 unless noted. This means that source files written
to use Eclipse SDK 2.0 APIs can be successfully compiled and run against Eclipse SDK 2.1 APIs. Since source incompatibilities are easy to deal with,
maintaining source compatibility is considered much less important than maintaining
contract and binary compatibility. Downward source compatibility is not supported.
If source files use new Eclipse SDK APIs, they will not be usable with an earlier
version of Eclipse SDK.
<p><b>Workspace Compatibility:</b> Eclipse SDK 2.1 will be upwards workspace-compatible
with Eclipse SDK 2.0 unless noted. This means that workspaces and projects created
with Eclipse SDK 2.0 can be successfully opened by Eclipse SDK 2.1 and upgraded
to a 2.1 workspace. This includes both hidden metadata, which is localized to
a particular workspace, as well as metadata files found within a workspace project
(e.g., the .project file), which may propagate between workspaces via file copying
or team repositories. Individual plug-ins developed for Eclipse SDK 2.1 should
provide similar upwards compatibility for their hidden and visible workspace
metadata created by earlier versions; 2.1 plug-in developers are responsible
for ensuring that their plug-ins recognize both 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 opened) by Eclipse SDK 2.1 will be unusable with an earlier version
of Eclipse SDK.&nbsp;Visible metadata files created (or overwritten) by Eclipse
SDK 2.1 will generally be unusable with earlier versions of Eclipse SDK.&nbsp;
<p><b>Non-compliant usage of API's</b>: 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 SDK API are inherently unsupportable
and receive no guarantees about compatibility within a single release much less
with an earlier release. Refer to <i><a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">How
to Use the Eclipse API</a></i> for information about how to write compliant
plug-ins.
<h2> Eclipse Project Subprojects</h2>
The Eclipse Project consists of 3 subprojects. Each subproject
is covered in its own section:
<blockquote><a href="#Eclipse Platform subproject">Eclipse Platform</a>
<br>
<a href="#Java development tooling (JDT) subproject">JDT - Java development
tools</a> <br>
<a href="#Plug-in development environment (PDE) subproject">PDE - Plug-in development environment</a></blockquote>
<p>For each subproject, the items listed reflect new features of the Eclipse Platform,
or areas where existing features will be significantly reworked. Each item indicates
the components affected by that work item (many items involve coordinated changes
to several components).
<h3>
<a name="Eclipse Platform subproject">Eclipse Platform subproject</a></h3>
The Eclipse Platform provides the most fundamental building blocks. The following items reflect new features of the Eclipse Platform, or areas
where existing features will be significantly reworked.
<h4>Committed Items (Eclipse Platform subproject)</h4>
<blockquote>
<p> <b>Improve startup time</b>.&nbsp; Progress was made
at improving startup times in 2.0; however, additional improvements are needed. In addition, we need to investigate deferring (or partially omitting) the
recovery of the UI state. [Platform Core, Platform UI]</p>
<p>
<b>Allow user customizable
key bindings.</b>&nbsp; Eclipse 2.0 supports configurable key bindings, but only
for editor key bindings, and only configured by a plug-in. The user should be
able to interactively customize the
key bindings for all workbench actions. There are additional customization possibilities including visible actions and perspective layout.
[Platform UI, SWT, Text, JDT UI]</p>
<p> <b>Improve update
manager.</b> Make continuing improvements to the Eclipse install and update
mechanisms. Improve support for installing and updating large products making
use of nested features. Make remote connections more configurable ( connection using a proxy server
behind firewall and authentication) and more robust (time outs). [Platform Core, Platform Install/Update]</p>
<p> <b>Enable DBCS on Linux.</b>
Support double-byte characters on the GTK and Motif window systems. [SWT]</p>
<p> <b>Add workbench
editor navigation
history.</b> The user should be able to navigate between workbench editors with web style back/forward actions.
(Ref: <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=5700">bug 5700</a>)&nbsp;
[Platform UI]</p>
<p> <b>Improve Ant support.</b> Add support to navigate from Ant error output
to the corresponding source. [Platform UI, Ant Core]</p>
</blockquote>
<h4>Proposed Items (Eclipse Platform subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse Platform subproject)</h4>
<blockquote>
<p><b>Add cheat sheets</b>.&nbsp; A cheat sheet is an instance of a simple kind
of workflow support used to help the user carry out a sequence of steps. For
example, &quot;create and deploy a plug-in" is a multi-step process that could
be made easier to follow if there was a guide, similar to a recipe that would
track the user's progress and provide both descriptive text that explains
the steps involved and integration with Eclipse to automate the process. The
Welcome Page editor is a simple example of a cheat sheet. Provide a standard
API for creating cheat sheets. [Platform UI]</p>
<p> <b>Add table of contents support to wizards.</b> Extend the workbench wizard
framework to allow Eclipse wizard developers to provide much more substantial
and significant user feedback. [Platform UI]</p>
<p> <b>Support floating toolbars and views.</b> Allow the user to customize the
workbench by creating floating toolbars and views. [Platform UI]</p>
<p> <b>Allow editors to open files outside workspace.</b> A common request is
to be able to open a file that is not part of the workspace using Eclipse.
In addition, applications would like to provide file extension associations
so that double-clicking on a file in the OS desktop would open the associated
Eclipse editor. The operations and capabilities available on these "outside
of the workspace" files would need to be defined. [Platform UI]</p>
<p><b>Improve serviceability. </b> Progress was made at improving serviceability
in 2.0; however, additional improvements are needed, particularly in dealing
with error conditions and reporting them in an appropriate manner. [Platform
Core, SWT, Platform UI]<br>
<br>
<b>Improve file encoding support.</b> Eclipse 2.0 uses a single global file
encoding setting for reading and writing files in the workspace. This is problematic;
for example, when Java source files in the workspace use OS default file encoding
while XML files in the workspace use UTF-8 file encoding. The Platform should
support non-uniform file encodings. (Ref: <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=5399">bug
5399</a>) [Platform Core, Platform UI, Text, Search, Compare, JDT UI, JDT
Core]</p>
<p>(<img border="0" src="new.gif" width="12" height="12"> recently deferred)
<b>Improve SWT support for right-to-left languages</b>.&nbsp;Allow the appropriate
widget orientation for right-to-left languages. [SWT]</p>
</blockquote>
<h4>Rejected Items (Eclipse Platform subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse Platform subproject.)
<h3> <a name="Java development tooling (JDT) subproject">Java development tools
(JDT) subproject</a></h3>
<a href="http://www.eclipse.org/jdt/index.html"> Java development tools</a> (JDT)
implements a Java IDE based on the Eclipse Platform. The following work items
reflect new features of JDT, or areas where existing features will be significantly
reworked.
<h4>Committed Items (Eclipse JDT subproject)</h4>
<blockquote>
<p> <b>Support building projects with circular dependencies.</b>&nbsp; Some users are
experiencing difficulty partitioning their work into independently-buildable projects. We want to add a mechanism to allow mutually dependent projects to be
built
successfully, while preserving current project build order behavior. (Ref: <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=10262">bug
10262</a>) [JDT Core, Platform Core]</p>
<p> <b>More flexible project layout.&nbsp; </b>Support source and output folders that are outside of the
workspace. This likely requires Platform Core support so that changes to these
folders can be reflected in resource deltas. [JDT Core, JDT UI, Platform
Core, Platform UI, Team]</p>
<p> <b>Support multi-JAR
system libraries.</b> Some JREs (including Mac OS X and IBM 1.4) package&nbsp;
the Java system class libraries in several JAR files. Improve support for system
class libraries so that it is more convenient to develop and run against them. [JDT
Core, JDT UI]</p>
<p> <b>Add new refactorings</b>. Support additional
refactoring actions, including extract interface, and extract constant. [JDT
Core, JDT UI]</p>
</blockquote>
<h4>Proposed Items (Eclipse JDT subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse JDT subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Rejected Items (Eclipse JDT subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse JDT subproject.)
<h3>
<a name="Plug-in development environment (PDE) subproject">Plug-in development environment (PDE) subproject</a></h3>
The <a href="http://www.eclipse.org/pde/index.html"> plug-in development environment</a>
(PDE) consists of&nbsp;tools for developing plug-ins for the Eclipse Platform.
The following work items reflect new features of PDE, or areas where existing
features will be significantly reworked.
<h4>Committed Items (Eclipse PDE subproject)</h4>
<blockquote>
<p> <b>Improve build class path for plug-in projects.</b> Plug-ins that make
direct reference to JAR libraries of prerequisite plug-ins are vulnerable
to version ids in plug-in embedded in directory names. The alternative, using
binary library plug-ins for each prerequisite plug-in, leads to a profusion
of projects in the workspace. PDE will offer a third alternative based on
JDT class path containers that avoids these shortcomings and interoperates
with existing plug-in projects.</p>
<p> <b>Add support for update sites.</b> Setting up an Eclipse update site and
building its plug-ins and features is not straightforward. PDE will make it
convenient to define the layout of an update site and create the update site's
contents.</p>
<p> <b>Improve usability.</b> F1 help for all PDE dialogs; improved PDE form
editors; improved plug-in manifest editor Extensions page; more user-friendly
support for building plug-ins and features.</p>
</blockquote>
<h4>Proposed Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<h4>Deferred Items (Eclipse PDE subproject)</h4>
<blockquote>
<p> <b>Add template API.</b> API for PDE template wizards will be defined, allowing
other plug-ins to contribute templates for their extension points.</p>
</blockquote>
<h4>Rejected Items (Eclipse PDE subproject)</h4>
<blockquote>
<p><i>None at this time.</i></p>
</blockquote>
<p>(End of items for Eclipse PDE subproject.)
</body>
</html>