blob: 3f53f4c3db89c00f4d4f825ee7d8e8c79691ab77 [file] [log] [blame]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<title>Eclipse Platform/Core</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
</head>
<body>
<center>
<font class=indextop>core</font><br>
<font class=indexsub>the foundation of the platform</font><p></p>
<a href="../../main.html">[home]</a>
<a href="../../documents.html">[documents]</a>
<a href="../../downloads.html">[downloads]</a>
<a href="../../resources.html">[resources]</a>
<a href="../../planning.html">[planning]</a>
<a href="../../testing.html">[testing]</a>
</center>
<br>
<table BORDER=0 CELLPADDING=2 WIDTH="100%" >
<tr>
<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Planning</font></b></td>
</tr>
<tr>
<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
<td><b>Theme: Built to Last</b> <p><em>Platform/Runtime</em></p>
<ul>
<li><img src="../../images/small_progress.gif" width="14" height="5">
<em>(Performance)</em> Improvements on Registry Structure - Investigate
ways of making it smaller and more scalable. Consider radical changes.
Think outside the box.</li>
<li> <em>(Performance)</em> Resource Bundles Implementation - Both speed
and space. Look at array bundles. More efficient NL tooling. (cross
team - Platform/Runtime, JDT/UI)</li>
<li><em>(Performance)</em> Runtime Bundles - Flush the state structure.
Reduce the memory footprint of the running framework by streaming the
state on startup and not keeping the state in memory.</li>
<li><em>(Outreach)</em> Help people write dynamic code
<ul>
<li>all bundles in the RCP should be completely dynamic aware and
dynamic enabled (all teams)</li>
<li> enable dynamic awareness for addition in all plug-ins (all teams)</li>
</ul>
</li>
<li> <em>(Outreach)</em> Correct use of new runtime APIs: preferences,
jobs, encoding/content type, OSGi services (identify use cases) (all
teams)</li>
<li>JXE adaptor</li>
<li>Reduce class-library dependencies - Investigate having bundles included
in the RCP be able to compile and run against 1.3 class libraries.</li>
<li>OSGi spec work:
<ul>
<li>working on OSGi specs </li>
<li>finish PlatformAdmin APIs for installing/uninstalling/updating
bundles</li>
<li>introduce support for batched bundle events (thus making batched
registry change events viable)</li>
<li>framework layering</li>
<li>API changes</li>
</ul>
</li>
<li>Implementing OSGi R4 - A new version of the OSGi spec will be released
soon and the OSGi code must be updated to conform to any changes.</li>
<li>Running on another OSGi implementation (probably will be deferred)</li>
<li>OSGi test suite integration - OSGi includes a group of test suites
for compliance. We should integrate these tests with out automated suites
to be run against builds.</li>
<li>Dynamic Support - Inclusion of OSGi into the runtime has given Eclipse
the ability for dynamic bundles. We need to expand the infrastructure
for supporting dynamic awareness and enablement. Investigate the use
of OAF. (OSGi Application Framework)</li>
<li>evaluate the need of special support to allow automatic/product-driven/user-driven
integration of non-plug-in code into Eclipse - need to investigate community
needs, current workarounds, and carefully understand possible drawbacks.
Use cases: providers of standard APIs (such as JDBC, JNDI, etc) (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=3074">bug
3074</a>)</li>
<li>Programatically add registry entries - Currently the only way that
items are added to the extension registry is via files and parsing.
We need to investigate whether or not there is a need for being able
to programatically add items to the registry. One problem to consider
is persistence.</li>
<li>Split up Runtime - The org.eclipse.core.runtime plug-in contains a
lot of disjoint functionality and can possibly be split up into separable
components along the lines of the extension registry, preferences, job
manager, content type, etc.</li>
<li><img src="../../images/small_x.gif" width="10" height="12"> <em>(Deferred)</em>
Rolling Log File - The Eclipse log file is ever-increasing and could
be changed to roll and stay at a managable size. Note that this might
be deferred since users are able to delete/manage the log file via the
PDE Error Log View.</li>
<li>Stub Plug-ins - Investigate shipping plug-ins which have only the
plugin.xml and code/resources are downloaded as you need them.</li>
<li>Content types - For 3.0 we created new content type APIs. We need
to fill in the implementation and then ensure that people are taking
advantage of it. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=67884">bug
67884</a>)</li>
<li><img src="../../images/small_check.gif" width="10" height="11"> Path
issues: There are some user problems coming up where they have already
existing directory structures on disk and they would like to create
these project within Eclipse but we don't allow them because their path
names contain &quot;illegal&quot; characters such as slashes and colons.(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=24152">bug
24152</a>) <a href="../documents/path_changes.html">See proposed solution</a>.</li>
</ul>
<p><em>PDE/Build</em></p>
<ul>
<li>Build RPMs for Linux - The build support should be able to build RPMs
for Linux since this is one standard that Linux system use for installation.</li>
<li>PDE/Build test suites - We should be able to create automated test
suites for a lot of the functionality in the PDE/Build component.</li>
<li>Adapt to OSGi R4 changes - Since a new version of the OSGi spec will
be available, we need to react to the changes.</li>
</ul>
<p><em>Platform/Resources</em></p>
<ul>
<li><img src="../../images/small_progress.gif" width="14" height="5">
Improve IndexedStore
<ul>
<li><img src="../../images/small_x.gif" width="10" height="12"> <em>(Deferred)</em>
Cloudscape is a Java database implementation that has been donated
to Apache by IBM. We should investigate making it an Eclipse plug-in
and then using it for implementation of the IndexedStore. (which
is the backing store for persistent properties and the history store)</li>
<li><img src="../../images/small_progress.gif" width="14" height="5">
Investigate other alternatives for the history/property store implementation.
</li>
</ul>
</li>
<li><img src="../../images/small_check.gif" width="10" height="11"> Better
story for external tool builders - There are bugs when people have multiple
external tool builders on the same project. Namely, we have been using
the builder-id as a unique way to identify the builder, but since the
external tool builder is a wrapper for the script that is really doing
the work, the id is not unique across the scripts. Fixing this problem
will require a change in the workspace tree file format. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=21029">bug
21029</a>)</li>
<li>Allow merge for Copy/Move - Current implementation of copy/move requires
that the destination resource/path does not exist. We should investigate
allowing merge in the workspace tree. This would benefit refactoring
actions. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=31883">bug
31883</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29838">bug
29838</a>)</li>
<li><img src="../../images/small_check.gif" width="10" height="11"> APIs
for maintaining file permissions - There are currently bugs related
to copying/moving resources on Linux machines and the file permissions
are not retained. This is especially apparent in the case where we end
up doing a copy/move by transferring stream data rather than a file-system
level copy/move (for instance across volumes) and when we restore file
contents from local history. In these cases the file permissions are
not retained. This bug is a candidate for deferral as it can be argued
that support should be in java.io.File. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=20575">bug
20575</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26100">bug
26100</a>)</li>
<li>Share metadata in the repository - In Eclipse 3.0 we enabled project
preferences which allows the sharing of project-level user settings.
We need to investigate taking this support further...for instance in
sharing markers, persistent properties, and other resource metadata.
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=21411">bug 21411</a>,
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26809">bug 26809</a>)</li>
<li>Improve Debugging Information - We need to improve some of the debugging
information in the Resources plug-in. One thing which people have been
asking for is a way to find out &quot;who triggered the build?&quot;.</li>
<li><em>(Performance)</em> Fix ResourcesPlugin#startup code - The Resources
plug-in agressively tries to load the workspace during its startup but
that is not only unnecessary but also undesirable.</li>
<li>File encodings - For 3.0 we created new file encoding APIs to allow
for encoding changes to be visible in resource deltas. We need to fill
in this implementation. There are also new APIs for content type changes
at the Runtime level. We need to react to these changes and reflect
them in resource deltas. Note that there will be down-stream changes
for other teams to adapt to. (JDT/Core for instance) (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=59899">bug
59899</a>)</li>
<li>Project natures could give hints about the content type for files.
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=69640">bug 69640</a>)</li>
<li><img src="../../images/small_check.gif" width="10" height="11"> Convert
our existing performance tests to take advantage of the new performance
framework provided by RelEng.</li>
<li>Support overriding string values from properties files. Basically,
if a plugin defines a string in plugin.properties or in a java resource
file, someone should be able to provide alternate values for some strings.
(request from Platform/Update)</li>
</ul>
<p>&nbsp;</p></td>
</tr>
<tr>
<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
<td><p><b>Theme: Rich Client Platform (RCP)</b> </p>
<p><em>Platform/Runtime</em></p>
<ul>
<li>End-to-End Development Story (cross team)</li>
<li>End-to-End Application Story (installation, running, configuration,
updating, etc) (cross team)</li>
<li>JNLP/WebStart (Java Network Launch Protocol) (cross team - Platform/Runtime,
Platform/Update)</li>
<li>Examples - In Eclipse 3.0 we laid the foundation for a Rich Client
Platform. Now people are interested in it and want to use it and the
best way to educate them is to write example of our own that we can
make available. (all teams)</li>
<li>Add support for framework extensions.</li>
</ul>
<p><em>PDE/Build</em></p>
<ul>
<li>JXE support - supporting framework for building JXEs</li>
</ul>
<p><em>Platform/Resources</em></p>
<ul>
<li>Allow markers for non-resources or move markers to own plug-in? (org.eclipse.core.runtime.markers)
Need to investigate and list use cases.</li>
</ul>
<p>&nbsp;</p></td>
</tr>
<tr>
<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
<td><b>Theme: Large-scale Development</b> <p><em>PDE/Build</em></p>
<ul>
<li>PDE support for exporting to an update site (updating the site.xml)</li>
<li>Building against an update site - Currently we require all resources
to be local when building. We need to investigate being able to build
against JARs, etc which exist on update sites.</li>
</ul>
<p><em>Platform/Resources</em></p>
<ul>
<li>Logical vs Physical - IResource on the physical side -&gt; create
new logical layer and create a mapping (too many people already relying
on IResource as is) (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">bug
37723</a>) (cross team - Platform/Resources, Platform/Team)</li>
<li>Improve team control over resource operations - Investigate to see
if we still need to add more control over other opertions. Essentially
expanding the move/delete hook to include creation, etc. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37722">bug
37722</a>) (cross team - Platform/Resources, Platform/Team)</li>
<li>Remote workspace and remote resources - Investigate dealing with remote
workspaces and remote resources. (similar to support that was in Eclipse
0.5 where we had synchronizing on resource existance rather than content
and we would retrieve the contents when necessary)</li>
</ul>
<p></p></td>
</tr>
<tr>
<td ALIGN=RIGHT VALIGN=TOP><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
<td><p><strong>Theme: Broaden the Community</strong></p>
<p><em>Platform/Runtime</em></p>
<ul>
<li>Real RCP web presence, book, articles (all teams)</li>
</ul>
<p>&nbsp;</p></td>
</tr>
<tr>
<td ALIGN=RIGHT VALIGN=TOP><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
<td><p><strong>Other Components</strong></p>
<p>While coming up with our component plan, here are some potential issues/plan
items that we have identified in other components.</p>
<p><em>Platform/Update</em></p>
<ul>
<li> Better support for creating/managing internal mirrors</li>
<li> More widespread use of Update - We should use the update manager
to get milestone builds, etc. Use the technology we build!</li>
<li>Create an Eclipse Installer - We should be able to download a minimal
application which uses update site + checkboxes to install what you
want.</li>
<li>Adapt to OSGi R4 changes - Since a new version of the OSGi spec will
be available, we need to react to the changes. </li>
</ul>
<p><em>PDE/UI</em> </p>
<ul>
<li>Wizards for RCP - Part of the end-to-end RCP story. We should have
wizards for creating RCP applications, targeting an RCP platform, etc.</li>
<li>PDE to manage target manifests and make launching more efficient (incrementally
generate/maintain the manifests rather than relying on the runtime to
generate them on every launch). This improves performance and accuracy.
No more need for -clean.</li>
<li>Improve Bundle Tooling - We need to improve the manifest editor, etc.</li>
<li>feature request: File -&gt; Export -&gt; Into my currently running
dev (Java doits!)</li>
<li>Adapt to OSGi R4 changes - Since a new version of the OSGi spec will
be available, we need to react to the changes.</li>
<li>Targetting JAR'd plug-ins - In Eclipse 3.0 we have the ability to
run against (and update) plug-ins which are shipped as JAR files. We
need to expand this support so they can be included in the target platform
as well.<br>
</li>
</ul></td>
</tr>
</table>
</body>
</html>