core
the foundation of the platform

[home] [documents] [downloads] [resources] [planning] [testing]

Planning
Theme: Built to Last

Platform/Runtime

  • (Performance) Improvements on Registry Structure - Investigate ways of making it smaller and more scalable. Consider radical changes. Think outside the box.
  • (Performance) Resource Bundles Implementation - Both speed and space. Look at array bundles. More efficient NL tooling. (cross team - Platform/Runtime, JDT/UI)
  • (Performance) 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.
  • (Outreach) Help people write dynamic code
    • all bundles in the RCP should be completely dynamic aware and dynamic enabled (all teams)
    • enable dynamic awareness for addition in all plug-ins (all teams)
  • (Outreach) Correct use of new runtime APIs: preferences, jobs, encoding/content type, OSGi services (identify use cases) (all teams)
  • JXE adaptor
  • Reduce class-library dependencies - Investigate having bundles included in the RCP be able to compile and run against 1.3 class libraries.
  • OSGi spec work:
    • working on OSGi specs
    • finish PlatformAdmin APIs for installing/uninstalling/updating bundles
    • introduce support for batched bundle events (thus making batched registry change events viable)
    • framework layering
    • API changes
  • 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.
  • Running on another OSGi implementation (probably will be deferred)
  • 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.
  • 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)
  • 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) (bug 3074)
  • 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.
  • 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.
  • (Deferred) 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.
  • Stub Plug-ins - Investigate shipping plug-ins which have only the plugin.xml and code/resources are downloaded as you need them.
  • 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. (bug 67884)
  • 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 "illegal" characters such as slashes and colons.(bug 24152) See proposed solution.

PDE/Build

  • 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.
  • PDE/Build test suites - We should be able to create automated test suites for a lot of the functionality in the PDE/Build component.
  • Adapt to OSGi R4 changes - Since a new version of the OSGi spec will be available, we need to react to the changes.

Platform/Resources

  • Improve IndexedStore
    • (Deferred) 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)
    • Investigate other alternatives for the history/property store implementation.
  • 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. (bug 21029)
  • 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. (bug 31883, bug 29838)
  • 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. (bug 20575, bug 26100)
  • 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. (bug 21411, bug 26809)
  • 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 "who triggered the build?".
  • (Performance) 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.
  • 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) (bug 59899)
  • Project natures could give hints about the content type for files. (bug 69640)
  • Convert our existing performance tests to take advantage of the new performance framework provided by RelEng.
  • 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)

 

Theme: Rich Client Platform (RCP)

Platform/Runtime

  • End-to-End Development Story (cross team)
  • End-to-End Application Story (installation, running, configuration, updating, etc) (cross team)
  • JNLP/WebStart (Java Network Launch Protocol) (cross team - Platform/Runtime, Platform/Update)
  • 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)
  • Add support for framework extensions.

PDE/Build

  • JXE support - supporting framework for building JXEs

Platform/Resources

  • Allow markers for non-resources or move markers to own plug-in? (org.eclipse.core.runtime.markers) Need to investigate and list use cases.

 
Theme: Large-scale Development

PDE/Build

  • PDE support for exporting to an update site (updating the site.xml)
  • 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.

Platform/Resources

  • Logical vs Physical - IResource on the physical side -> create new logical layer and create a mapping (too many people already relying on IResource as is) (bug 37723) (cross team - Platform/Resources, Platform/Team)
  • 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. (bug 37722) (cross team - Platform/Resources, Platform/Team)
  • 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)

Theme: Broaden the Community

Platform/Runtime

  • Real RCP web presence, book, articles (all teams)

 

Other Components

While coming up with our component plan, here are some potential issues/plan items that we have identified in other components.

Platform/Update

  • Better support for creating/managing internal mirrors
  • More widespread use of Update - We should use the update manager to get milestone builds, etc. Use the technology we build!
  • Create an Eclipse Installer - We should be able to download a minimal application which uses update site + checkboxes to install what you want.
  • Adapt to OSGi R4 changes - Since a new version of the OSGi spec will be available, we need to react to the changes.

PDE/UI

  • Wizards for RCP - Part of the end-to-end RCP story. We should have wizards for creating RCP applications, targeting an RCP platform, etc.
  • 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.
  • Improve Bundle Tooling - We need to improve the manifest editor, etc.
  • feature request: File -> Export -> Into my currently running dev (Java doits!)
  • Adapt to OSGi R4 changes - Since a new version of the OSGi spec will be available, we need to react to the changes.
  • 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.