Development Resources Component Planning
Platform/Core Component Development Resources
Bugs
  • Priority 1
  • Resolved in the last week
  • Inbox - These are the bug reports which have been entered against the Platform/Core component and are either awaiting more information from originator or have not yet been verified as a bug. The general state of bugs in this query is uncategorized.
  • Open Bugs - These are the bug reports which have either been verified as real bugs or issues which should be investigated. Feature requests are not included in this list.
  • Feature Requests - These are the bug reports which are not bugs but are features that the user wishes to have added to the Core. They have been marked with a severity of enhancement.
Articles
Documents/Proposals (archive)
Plug-ins
The Platform/Core component consists of the following plug-ins: 
Mailing Lists
Examples/Contributions
  • The auto-refresh plug-in has been integrated into the SDK and now is included as a part of the latest Eclipse 3.0 builds.
  • Jed's Auto-refresh plug-in v2.1 from June 18, 2003. As described on the platform-core-dev mailing list. For use with Eclipse 2.1 and greater.
  • Jed's Auto-refresh plug-in for versions of Eclipse prior to 2.1 as described on the platform-core-dev mailing list.
  • Move/Delete Hook example for Team providers.

Update Site
For Eclipse 3.0 we are pushing to use the update technology more so the Core team now has an Update Site. Add the following URL to the update manager:

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/updates

Spies/Tools
The Platform/Core team has created a group of tools which help them when developing code or trying to debug problems and investigate bug reports. They have been developed as both plug-ins and headless utilities and are available here for download. Also check the Update Site.
  • Core Tools v1.1.0 - The first version of the tools to run on the Eclipse 3.0 runtime. This is mostly a port of the original tools but there are some new views (e.g., Eclipse Preferences view). There may be some issues... Works with org.eclipse.osgi from HEAD as of 20040505 or I builds starting the week of 05/10.
  • Core Tools v1.0.0 - A series of runtime and resource related views and perspectives. The runtime tools allow users to look which plugins and classes are loaded, discover why/when they were loaded, etc. The resource tools expose the behaviour/performance of builders and resource change listeners as well as the structure of deltas, the workspace and resources. The metadata tools allow you to inspect the data behind the scenes. To install on Eclipse 2.0.* and 2.1 prior to I20021127, get the patch below. Otherwise, just fetch this download, follow the instructions in the readme (also in the org.eclipse.core.tools/doc directory) and enjoy.
  • Core Tools v1.0.2 - This is the version of the core tools plugin that you should use for Eclipse release 2.1. The core tools patch is not required for this version. This update fixes a non binary-compatible change that was made within org.eclipse.core.resources, and appearing in all builds since I20030128. Some more information has also been added to the element tree spy. Fixes have been added on 2003/09/23 to fix a concurrency problem.
  • Core Tools Patch v1.0.1 - Apply this patch to if you want to run the Core Tools on Eclipse builds earlier than I20021127 (including 2.0.*). See the Core Tools install notes for details.
  • Workspace Re-Builder - Command-line utility program for basic restoration of a corrupt workspace. This first version will re-create your projects for you but will not restore your metadata. Check out the readme for more details.
Patches
Platform/Core Component Planning

Current Work

Work will now be focused on Eclipse 3.0. Rather than rolling out version 2.2 which would contain fixes and minor feature requests, it has been decided that we will take on more challenging problems. Please read Why Eclipse "3.0"? and the Eclipse 3.0 Project Plan.

Being done concurrently with the 3.0 work are bug fixes for service releases for Eclipse 2.1. For a list of problems which will be fixed for the Eclipse 2.1.1 release, check out the Bugzilla bug reports by clicking here.

Committed Items

[plan item] Improve file encoding support - Eclipse 2.1 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. [Platform Core, Platform UI, Text, Search, Compare, JDT UI, JDT Core] [Theme: User experience] (bug 37933, 5399)

[plan item] Support concurrent activities - In Eclipse 2.0 and 2.1, certain operations like builds and searches always run synchronously and block the user at the UI from doing work until the build has completed. The Eclipse Platform should support operations running asynchronously in the background, so that the user is not forced to be entirely idle while long-running operations are in progress. This will likely require an improved concurrency architecture with more explicit rules. [Platform UI, Platform Core, Platform Text, JDT Core, JDT UI, PDE] [Theme: Responsive UI] (bug 36957)

[plan item] Enable Eclipse to be used as a rich client platform - Eclipse was designed as a universal tool integration platform. However, many facets and components of Eclipse are not particularly specific to IDEs and would make equal sense in non-IDE applications (e.g., window-based GUI, plug-ins, help system, update manager). The Eclipse Platform should factor out and segregate IDE-specific facilities (e.g., everything having to do with workspace resources) so that a subset of it can be used as a rich client platform for building applications. [Platform Core, Platform UI, Platform Update] [Theme: Rich client platform] (bug 36967)

[plan item] Provide user settings - It should be possible to store user settings (preferences, compiler settings, repositories lists, etc.) that are not specific to a workspace separate from the workspace, so that they can be used in other workspaces or by other users. [Platform Core] [Themes: Rich client platform] (bug 36965)

[plan item] Remove dependency on Xerces - The Xerces plug-in currently provides XML support for the Eclipse platform. XML support is now incorporated into J2SE 1.4, and the presence of the Xerces plug-in can create conflicts. Eclipse Platform should consistently use the built-in XML support that ships with JDK 1.4, or possibly an alternative XML parser such as XMLPull which has a much smaller footprint. [Platform Core] (bug 37696)

Proposed Items

[plan item] Allow editors to open files outside workspace - A common request is to be able to use Eclipse to open a file that is not part of the workspace, or perhaps even one on a remote system. 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] [Themes: User experience] (bug 37935, 2869)

[plan item] Improve workspace synchronization with file system - A file resource in the workspace gets out of sync when the underlying file in the file system is created, deleted, or rewritten outside of Eclipse. File resources usually remains out of sync until the user explicitly hits Refresh. The Eclipse Platform should provide ways to keep the in-memory representation in sync with the file system; for example, by hooking OS file system callbacks where available, and by polling for file system changes in a background thread. [Platform Core, Platform UI] [Theme: User experience] (bug 36962, 2360)

[plan item] Content-type-based editor lookup - The choice of editor is currently based on file name patterns. This is not very flexible, and breaks down when fundamentally different types of content are found in files with undistinguished file names or internal formats. For example, many different models with specialized editors get stored in XML format files named *.xml. Eclipse should support a notion of content type for files and resources, and use these to drive decisions like which editor to use. This feature would also be used by team providers when doing comparisons based on file type. The several existing file-type registries in Eclipse should be consolidated. [Platform Core, Platform UI] [Theme: User experience] (bug 37668)

[plan item] Improve support for opening workspaces - Many users use multiple workspaces as a way to keep their different projects or work items separate. Currently, this requires launching Eclipse multiple times with different command line arguments, which is not particularly convenient for users. Moreover, when the command line argument is not specified, the workspace location defaults to a directory inside where the code for Eclipse is installed. Eclipse should improve how workspaces get opened, use a user-specific default workspace location more suitable for shared multi-user Eclipse installs, and facilitate switching between workspaces. [Platform Core, Platform UI] [Theme: User experience] (bug 37681)

[plan item] Support adding and removing plug-ins dynamically - Installation and configuration of features and plug-ins currently only happens during Eclipse Platform startup. The plug-in registry should be made dynamic so that features and plug-ins can be added or removed without necessarily having to restart Eclipse. This will also entail adding mechanisms for handling the arrival and departure of extensions and extension points. Additional mechanisms such as services will be added to support the dynamic programming model. Alternative runtimes (e.g., OSGi) which offer explicit support for dynamic components will also be investigated and used as appropriate. Plug-in developers will likely require additional support from PDE in writing and debugging well-behaved dynamic plug-ins. [Platform Core, PDE] [Theme: Rich client platform] (bug 37687)

[plan item] Allow plug-in deactivation - In order to scale to a large number of plug-ins, Eclipse does not activate a plug-in until its code is actually needed. However, once activated a plug-in remains active for the remainder of the session. Unfortunately, this means that an active plug-in will occupy memory space for its code and objects even if it is only used occasionally. Many users have sessions lasting days or weeks, and this bloat taxes processor memory and JVM performance. The analogy is a long play where the actors enter the stage on cue, but cannot leave it until the play is over. The Eclipse Platform should support plug-ins that can be safely deactivated when the user needs to recover valuable memory space. Another alternative is to provide a way to quietly shutdown and restart the Platform. [Platform Core, Platform UI] [Theme: Rich client platform] (bug 36956)

[plan item] Add a security model - Security needs are pervasive. The Eclipse Platform should provide the basic framework for a security mechanism that can be used by all plug-ins, including a simple credentials store and user authentication. Additionally, key parts of the Platform itself should be secured, such as the ability to install plug-ins, which might need to be restricted in certain products or for certain users. [Platform Core, Platform Update] [Theme: Rich client platform] (bug 37692)

[plan item] Improve team control over resource operations - Eclipse currently provides limited hooks (edit/save, move/delete) so that team providers can control or influence operations on resources in the workspace. However, there are some aspects and operations over which team providers have little or no influence, such as resource creation and copying. Eclipse should offer team providers better control over resource operations. [Platform Core, Platform Team] (bug 37722)

[plan item] Support logical resources - The Eclipse Platform supports a strong physical view of projects, files, and folders in the workspace. However, there are many situations where a physical view is not the most salient or useful for many purposes. In some cases, multiple distinct objects happen to be stored in a single file, like an archive. Conversely, in other cases, something that is logically a single object is stored across multiple files. This discrepancy between logical and physical creates problems for common operations such as searching, comparing, and versioning, which need to work in the physical realm. Eclipse should support some way of mapping between a logical view and the physical organization of files on disk. [Platform Core, Platform UI] (bug 37723)

Other Items

Improve adapter infrastructure - there are a number of limitations in the current IAdapterManager infrastructure. A number of plan items in platform UI and JDT UI are running up against these limitations, so they need to be addressed for Eclipse 3.0.

Improve User Experience - As a first-time Eclipse user there are many non-obvious problems that you can run across and this plan item is being used to collect them all. Some current problems include (but are not limited to): default location of the workspace, separation of user settings and plug-in metadata, multiple workspaces, and translation of messages presented to the user from the Eclipse executable.

Improve User Experience for Builds - Users are confused by certain aspects of the Eclipse build story, and would like some increased flexibility in deciding what gets built in large workspaces. This proposal deals with making project builds work as the user expects, removing confusing build options, and adding the notion of working set builds.

Misc org.eclipse.core.runtime work/investigation:

  • Look at places in Runtime where we are using Strings and String logic and we should/could replace this with the use of objects like Paths. Need to weigh this against potential performance issues. (bug 19507)
  • The registry cache is complicated. Investigate simplifying it. Ensure to keep the lazy loading work. Are there any other places where we can make similar improvements? (bug 27064)
  • Provide a specification for plug-in registry resolution. (bug 36504)
  • Clear the log file periodically or make it a rolling log file. (bug 22765)
  • We have had class loader problems w.r.t. #createExecutableExtension for a while. Investigate what we can do to fix these. (bug 5875)
  • Investigate changing the classloader lookup order. parent/self/prereq -> parent/prereq/self
  • Make Fragments Real via API? There is currently no way to get useful information about fragments. We need to add to our APIs and make fragments real. (bug 14460)
  • Build Id in Log File - We would like to have the build id in the log file. This needs to be done in conjunction with work from the Update team. We also need to define what a build id is. (bug 8214)

Misc org.eclipse.core.resources work/investigation:

  • Concurrency issues with the index store (persistent properties and local history)
  • New APIs for setting and maintaining file permissions. (bug 20575, 26100)
  • Change copy/move to merge the source with the destination. (bug 31883, 29838)
  • Sharing metadata in the repository. (bug 21411, 26809)
  • Markers on non-resources.
  • Remote resources -> syncing on existence vs content.
  • Make everything a linked resource?
  • Add more to the move/delete hook (copy, create, etc). This is related to the Team/Resource Integration plan item. (bug 13530)
  • Lifecycle of persistent/session properties -> what happens on copy/move?
  • Lazy persistent properties -> kept in memory and then written out to disk on workspace shutdown/save/snapshot
  • When do builders run?
    • currently the decorator thread finds a resource which is out of sync but can't do a refresh
    • builders can only run when you say they can (when you finish an action)
    • currently you have to think about what you are doing because in some cases you don't want builders to run
    • shouldn't have to be aware of builders when you are writing the code in your plug-in
  • Workspace lock granularity. (bug 35869)
  • Delta notification for particular resource types (project, Java, etc)
  • Import/Export of preferences...ensure that plug-ins use the Preference mechanism to take advantage of this
  • Natures and capabilities (bug 31939, 36959)
  • Simplier resource model. Resources without builders, markers, etc etc.
  • pre-validation of Core API methods -> Can I create this? Can I move this? Request by JDT Refactoring. (really just a request for transactional operations?)


Deferred Items

  • [plan item] Improve local history (bug 37679)
  • [plan item] Add capabilities (bug 36959)
  • [plan item] Support workspace checkpoint and rollback (bug 36958)
  • [plan item] Improve message bundles (bug 37712)
  • [plan item] Improve plug-in registry (bug 37715)


Eclipse 3.0 Top 5 Plan

This is a list of the top 5 items that we will be working on for the rest of the Eclipse 3.0 release cycle. (M7 -> Release)

  1. Responsive UI
    • Mainly documentation and client enablement left to do.
    • Investigation into current UI performance problems.
  2. User Settings
  3. File Encodings
  4. Runtime
    • run from JARs
    • enablement (doc, articles, working with other teams, etc)
    • robustness/use case coverage
  5. PDE-Build
    • bring up to speed with new runtime requirements (need to build JARs if want to run from JARs!)

Milestone Plan (3.0 M9) - May 7, 2004

  • File Encoding & Content Type Registry [rafael]
    • Core APIs are implemented.
    • Framework for guessing encoding is in as well as a basic implementation.
    • org.eclipse.core.resources uses this.
    • Text is using new encoding work.
    • JDT/Core conversion is in progress.
  • User Settings [dj]
    • Thread safety review.
    • Flush out plug-in customization story.
    • Bug fixing as more people use it.
    • Documentation.
  • Synchronization with the Filesystem [john]
    • Dropping FAM for Linux.
    • Improvements to polling support.
    • Finding a home in the preference pages.
  • Concurrent Operations [john]
    • Support and Documentation.
  • Runtime [pascal, rafael, jeff, tom, jenn]
    • Code review.
      • Remove TODOs.
      • Robustness.
      • Improved Logging.
    • Reduce JRE requirements.
    • Shared location management.
    • Working with other teams to remove requirements on runtime.compatibility.
  • PDE-Build [pascal]
    • Continued progress to work with new runtime.
    • Help RelEng with migration of work into the build process.
  • Remove Dependancy on Xerces [dj]
    • SDK plug-ins removed dependancies a long time ago.
    • Will start removing org.apache.xerces plug-in from the build.
    • Need to update features (releng to release changes) and core.map file.
  • Performance [all]
    • Performance pass on new runtime.
    • Use tooling to identify potential problem areas.
  • Documentation [all]
    • Document new features.
    • Ensure old documentation still makes sense.
    • Ensure new APIs/javadoc is flushed out.
    • Extension point schemas for new extension points.
  • Core Tools and Spies [jeff]
    • Use bug 56409 to track progress.
    • Want to have tools working and "converted to 3.0" by second week of April.

Milestone Plan (3.0 M8) - March 26, 2004

  • File Encoding [rafael]
    • Initial APIs released for M7.
    • Working on encoding determination in Runtime.
    • Modification of Resources implementation to use new APIs.
  • User Settings [dj]
    • APIs released to HEAD immediately after M7
    • Aid in client education and migration.
  • PDE-Build [pascal]
    • Continue to modify to work with new runtime.
  • Expressions in XML [johna]
    • Released initial APIs M7
    • Support/modification as new expressions plug-ins are released to HEAD.
  • Concurrent Operations [johna]
    • Support and documentation.
  • Runtime [pascal, rafael]
    • Continued work on new runtime.
    • Shooting for functional completeness.
  • Scoped Builds [johna]
    • Investigation into new plan item for scoped builds. [bug 50816]
  • Documentation [all]
    • We need to document all new function (this is a continuous item through all upcoming milestones)

Milestone Plan (3.0 M7) - February 13, 2004

  • File Encoding [rafael]
    • Andre and Rafael to continue work based on Andre's proposal for file encoding support.
  • User Settings [dj]
    • Proposal to be finished and available for comments.
    • Based on feedback from the proposal, initial implementation to be started.
  • Concurrent Operations [john]
    • Continued effort on the "Responsive UI" plan item.
    • Main effort left is documentation.
    • There are current open UI performance problems. These need to be investigated to find the source of the problem.
    • See the details page for more info.
  • EclipseCon [john, pascal]
    • Preparations continue for the Eclipse conference (Feb 2 to Feb 5)
  • Auto-Refresh [john]
    • Continued from M6 plan.
    • Work has been done to integrate the Auto-Refresh plug-in with the Core.
    • It has also been modified to use the new JobManager APIs.
    • This work needs to be reviewed and released to the builds.
  • Expressions in XML [dj]
    • As part of the work to allow third-party plug-ins to contribute to refactoring, Dirk has come up with a proposal for expression evaluation in plugin.xml files. Although most of this work will live in a separate plug-in, there is a certain degree of work which must be incorporated into the Core Runtime plug-in. Specifically the code for the enhancement bug 32498.
  • Runtime [pascal, rafael]
    • We would like to be able to run from JARs rather than having a scattered directory structure.
    • Investigation of running without a workspace (-nodata)
  • PDE-Build [pascal]
    • Expected to continue into M8
    • Work with new runtime.
    • Among other items, we need to be able to build JARs if we plan on running from them.
      • Need to modify the classpath computation for the compiler
      • Need to be able to assemble the JARs in the required format
      • Would like to replace the constructed plug-in registry information with State objects
  • Documentation [all]
    • We need to document all new function (this is a continuous item through all upcoming milestones)

Milestone Plan (3.0 M6) - December 19, 2003

  • Bug Fixing
    • Normally I don't include this as one of the things we are working on, but the M6 milestone has been targeted as one in which the teams will be making a conserted effort to reduce the defect backlog.
  • Concurrent Operations
    • A dynamic team has been constructed to work towards solving the remaining issues for the User Responsiveness plan item.
    • A new deadlock detection algorithm has been put into place and is being reviewed and tested.
    • See the details page for more info.
  • Rich Client Platform
    • We hope to have the new runtime as proposed by Equinox, integrated into the Core development stream.
    • Here is some documentation about the new runtime.
  • User Settings
    • TBD
  • File Encodings
    • Andre is currently working on the File Encoding issue, with Rafael as his Core team contact.
  • Auto-Refresh
    • Work has been done to integrate the Auto-Refresh plug-in with the Core.
    • It has also been modified to use the new JobManager APIs.
    • This work needs to be reviewed and released to the builds.
Milestone Plan (3.0 M5) - November 21, 2003 (based on 4 people, 6 weeks each)

  • Concurrent Operations (6 weeks)
    • A dynamic team has been constructed to work towards solving the remaining issues for the User Responsiveness plan item.
    • See the details page for more info.
  • Rich Client Platform (12 weeks)
    • See the Equinox home page for more info.
  • User Settings (4 weeks)
    • This plan item has been put off for too long. Goal is to have APIs defined by M5. If we can't get this done, then the chance of completing this item for 3.0 is minimal.
  • Remove Dependancy on Xerces (1 week)
    • Remove dependancy on Xerces code from boot, runtime, resources, pde-build, and webdav.
    • See the details page for more info.
  • RCP Transformations (1 week)
    • As part of the RCP work, some of the UI plug-in was refactored. This includes separation of the org.eclipse.ui plug-in into multiple plug-ins as well as the moving of extension points to different plug-ins. (and thus having a different id)
    • After meeting with people from UI and PDE, we determined that we need to be able to handle these transformations at the Core level in the plug-in parser.
  • File Encodings (0 weeks)
    • There is no active work currently being done on this plan item due to lack of resources.

Milestone Plan (3.0 M4) - October 10, 2003 (based on 4 people, 6 weeks each)

  • Concurrent Operations (6 weeks)
    • We are hoping that by the end of M4 most of the Platform/Core implementation will be in place.
    • A good deal of time will need to be spent on FAQs, support, and general education of how to use the new features.
    • See the details page for more info.
  • Rich Client Platform (9 weeks)
    • See the details page for more info.
  • User Settings (3 weeks)
  • Remove Dependancy on Xerces (3 weeks)
    • Still waiting for approval.
    • Once approved then majority of time will be documentation and education and helping others to use the new plug-in.
    • See the details page for more info.
  • File Encoding (3 weeks)
  • Improved User Experience
    • Includes: multiple workspaces, workspace synchronization, editing files outside of the workspace, and more.
    • See the details page for more info.

Milestone Plan (3.0 M3) - August 29, 2003 (based on 4 people, 5 weeks each)

  • Concurrent Operations (5 weeks)
    • Continued from M2 plan.
    • See the details page for more info.
  • Rich Client Platform (10 weeks)
    • Continued from M2 plan.
    • See the details page for more info.
  • Remove Dependancy on Xerces (3 days)
    • Continued from M2 plan
    • See the details page for more info.
  • File Encoding
    • Continued from M2 plan.
    • The RFC has been published to the web.
    • See the details for more info.
  • User Settings
    • Continued from M2 plan.
    • The RFC has been published by the Team team. During the M3 phase, we hope to provide more input and become more involved in the solution. (since most of it will be living in the Core Runtime space)
    • See the Team team page for more details.
  • Session Tests
    • Continued from M2 plan.
    • There has been more work than anticipated with co-ordinating the session tests and the automated test framework so work continues through to M3.
  • Improved User Experience
    • See the details page for more info.
  • Vacation (4 weeks)
    • It's summer time!

Milestone Plan (3.0 M2) - July 18, 2003 (based on 4 weeks before the milestone)

  • Concurrent Operations (4 weeks)
    • See the details page for more info.
  • Rich Client Platform (8 weeks...2 people, full-time for 4 weeks)
    • See the details page for more info.
  • Remove Dependancy on Xerces (1 week)
    • See the details page for more info.
  • File Encoding (4 days)
    • Gather requirements from community.
    • Enhance RFC based on gathered information.
  • User Settings (4 days)
    • Participate in RFC discussions.
    • Most likely there will be coding at the Core level, depending on which solution is decided on.
  • Session Tests (3 days)
    • Modify the Core session tests to be included in the RelEng automated tests.
  • PDE-Build (4 days)
    • Bug fixing.
    • Helping RelEng with integration of the new builder code into the build process.
    • Releasing new PDE-Build into HEAD and the integration builds.
  • Tools (3 days)
    • Code review and (finally!) release the workspace restorer plug-in to the web site.

Test Plans

Click here for the Core test plan for 3.0.