Eclipse Platform/Core

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