Heads up: Eclipse 3.2 Draft Plan
There's a new revision to the Eclipse Platform Project Draft 3.1 Plan. This last one was published August 5th (Friday). It's a good idea to pay attention to these when they come out, especially with regards to the plugin APIs. The first milestone (M1) should hit the streets on or about August 12th. According to the draft plan, version 3.2 won't be finally released until sometime in 2Q2006. Since they only have four milestone releases listed so far, and the fourth is targeted for mid-December, I have to wonder what is going to happen in the next 3-6 months after the December milestone release. I hope it comes out a lot sooner.
Here are some of the proposed items for 3.2 that I'm most interested in.
Support logical model integration. The Eclipse Platform supports a strong physical view of projects containing resources (files and folders) in the workspace. However, there are many situations where plug-in developers would prefer to work with a logical model that is appropriate to their domain. Eclipse should ease the task for plug-in developers who want to make logical model-aware plug-ins. To do this, Eclipse should provide more flexible mechanisms for contributing actions on models that do not have a one-to-one mapping to files on the users hard disk. This would, for example, allow a team provider's repository operations to be made available on logical artifacts. In addition, existing views like the navigator and problems view should be generalized to handle logical artifacts and, in general, there should be better control over what is displayed in views and editors based on the logical models that the end user is working on. [Platform Core, UI, Team] (37723) [Theme: Design for Extensibility]
Provide more flexible workspaces. Currently in Eclipse there is a direct connection between IResources and files and directories on the local file system. Eclipse should loosen this connection, by abstracting out its dependency on java.io.File, and allowing for alternative implementations. This would enable, for example, uses where the workspace is located on a remote server, or accessed via a non-file-based API, or has a non-trivial mapping between the resources and the physical layout of the files. [Platform Resources, Text] (106176) [Theme: Design for Extensibility, Enterprise Ready]
Update Enhancements. As the number and range of Eclipse plug-ins continues to grow, it becomes increasingly important to have a powerful update/install story. For instance, if more information about an Eclipse install was available earlier, it would be possible to pre-validate that it would be a compatible location to install particular new features and plug-ins. This information could also be used to deal with conflicting contributions. Update should also be improved to reduce the volume of data that is transferred for a given update, and PDE should provide better tools for creating and deploying updates. [Update, Platform Runtime, PDE] (106185) [Theme: Enterprise Ready]
I'm going to pay close attention to update enhancements. Keeping track of plugins and being able to manage them effectively is going to be crucial for Eclipse and NetBeans if they are to continue to evolve and grow.
Provide more support for large scale workspaces. In some situations, users have workspaces containing hundreds of projects and hundreds of thousands of files. Scoped builds and working sets have become important tools for these users, and the performance optimizations done in Eclipse 3.1 have proven helpful. Eclipse should have even more support for dealing with very large workspaces, including improved searching, filtering, working sets, and bookmarks. This goes hand-in-hand with ongoing work to discover and address performance issues. [Platform UI, Resources] (106192) [Theme: Scaling Up, Enterprise Ready]
Enhance the text editor. The Eclipse Text component provides a powerful editing framework that is useful in many contexts, but some of its capabilities are currently only available in the Java editor. The Java editor should be opened up to allow more general access to the reconciling, code assist, and template proposal mechanisms. Other enhancements to the look and feel of the editor should also be considered in areas such as the Find/Replace dialog, showing change history and comments in the editor, and annotation roll-overs. [Platform Text] (106194) [Theme: Design for Extensibility]
Improve UI Forms. UI Forms are increasingly being used in the Eclipse user interface. The UI Form support should be improved to allow for more pervasive use in 3.2. Critical widget functionality should be moved to SWT to ensure quality and native look and feel. The remaining UI Forms code (minus FormEditor) should be pushed down into JFace so that it is available in the Eclipse workbench. [SWT, UI, Help] (106203) [Theme: Simple to Use, Design for Extensibility]
Add support for Java SE 6 features. Java SE 6 (aka "Mustang") will likely contain improvements to javadoc tags (like @category), classfile specification updates, pluggable annotation processing APIs, and new compiler APIs, all of which will require specific support. [JDT Core, JDT UI, JDT Text, JDT Debug] (106206) [Theme: Appealing to the Broader Community]
Improve refactoring. Refactoring currently relies on a closed world assumption. This means that all of the code to be refactored must be available in the workspace when the refactoring is triggered. However for large distributed teams, the closed world approach isn't really feasible. The same is true for clients which use binary versions of libraries where API changes from one version to another. In 3.2 the closed world assumptions will be relaxed in such a way that a refactoring executed in workspace A can be "reapplied" on workspace B to refactor any remaining references to the refactored element. Furthermore, existing refactorings will be improved to preserve API compatibility where possible (for example when renaming a method, a deprecated stub with the old signature will be generated that forwards to the new method). [JDT Core/UI] (106207) [Theme: Scaling Up].
API-aware tools. Given the importance that the Eclipse community places on stable, robust APIs, having good support for their implementation is critical. The support within Eclipse for describing APIs should be improved, along with better tools from assisting developers to stick to APIs provided by other plug-ins. [PDE, JDT] (106213) [Theme: Enterprise Ready]
Improve PDE build. PDE Build is fundamental to how the Eclipse Platform releases are produced. It is also increasingly being used by other Eclipse projects and in the wider community. Potential improvements to PDE build include parallel cross-building, incremental building of plug-ins, increased integration with the workspace model, and support for additional repository providers. [PDE] (106214) 106214[Theme: Enterprise Ready]
There's a log more to read, and there is the link on the page to API change tracking. If they deliver most or all of what is targeted (and not just my interest list), then Eclipse 3.2 is going to be a powerful challenger. It will be interesting to see how NetBeans responds.
Here are some of the proposed items for 3.2 that I'm most interested in.
Support logical model integration. The Eclipse Platform supports a strong physical view of projects containing resources (files and folders) in the workspace. However, there are many situations where plug-in developers would prefer to work with a logical model that is appropriate to their domain. Eclipse should ease the task for plug-in developers who want to make logical model-aware plug-ins. To do this, Eclipse should provide more flexible mechanisms for contributing actions on models that do not have a one-to-one mapping to files on the users hard disk. This would, for example, allow a team provider's repository operations to be made available on logical artifacts. In addition, existing views like the navigator and problems view should be generalized to handle logical artifacts and, in general, there should be better control over what is displayed in views and editors based on the logical models that the end user is working on. [Platform Core, UI, Team] (37723) [Theme: Design for Extensibility]
Provide more flexible workspaces. Currently in Eclipse there is a direct connection between IResources and files and directories on the local file system. Eclipse should loosen this connection, by abstracting out its dependency on java.io.File, and allowing for alternative implementations. This would enable, for example, uses where the workspace is located on a remote server, or accessed via a non-file-based API, or has a non-trivial mapping between the resources and the physical layout of the files. [Platform Resources, Text] (106176) [Theme: Design for Extensibility, Enterprise Ready]
Update Enhancements. As the number and range of Eclipse plug-ins continues to grow, it becomes increasingly important to have a powerful update/install story. For instance, if more information about an Eclipse install was available earlier, it would be possible to pre-validate that it would be a compatible location to install particular new features and plug-ins. This information could also be used to deal with conflicting contributions. Update should also be improved to reduce the volume of data that is transferred for a given update, and PDE should provide better tools for creating and deploying updates. [Update, Platform Runtime, PDE] (106185) [Theme: Enterprise Ready]
I'm going to pay close attention to update enhancements. Keeping track of plugins and being able to manage them effectively is going to be crucial for Eclipse and NetBeans if they are to continue to evolve and grow.
Provide more support for large scale workspaces. In some situations, users have workspaces containing hundreds of projects and hundreds of thousands of files. Scoped builds and working sets have become important tools for these users, and the performance optimizations done in Eclipse 3.1 have proven helpful. Eclipse should have even more support for dealing with very large workspaces, including improved searching, filtering, working sets, and bookmarks. This goes hand-in-hand with ongoing work to discover and address performance issues. [Platform UI, Resources] (106192) [Theme: Scaling Up, Enterprise Ready]
Enhance the text editor. The Eclipse Text component provides a powerful editing framework that is useful in many contexts, but some of its capabilities are currently only available in the Java editor. The Java editor should be opened up to allow more general access to the reconciling, code assist, and template proposal mechanisms. Other enhancements to the look and feel of the editor should also be considered in areas such as the Find/Replace dialog, showing change history and comments in the editor, and annotation roll-overs. [Platform Text] (106194) [Theme: Design for Extensibility]
Improve UI Forms. UI Forms are increasingly being used in the Eclipse user interface. The UI Form support should be improved to allow for more pervasive use in 3.2. Critical widget functionality should be moved to SWT to ensure quality and native look and feel. The remaining UI Forms code (minus FormEditor) should be pushed down into JFace so that it is available in the Eclipse workbench. [SWT, UI, Help] (106203) [Theme: Simple to Use, Design for Extensibility]
Add support for Java SE 6 features. Java SE 6 (aka "Mustang") will likely contain improvements to javadoc tags (like @category), classfile specification updates, pluggable annotation processing APIs, and new compiler APIs, all of which will require specific support. [JDT Core, JDT UI, JDT Text, JDT Debug] (106206) [Theme: Appealing to the Broader Community]
Improve refactoring. Refactoring currently relies on a closed world assumption. This means that all of the code to be refactored must be available in the workspace when the refactoring is triggered. However for large distributed teams, the closed world approach isn't really feasible. The same is true for clients which use binary versions of libraries where API changes from one version to another. In 3.2 the closed world assumptions will be relaxed in such a way that a refactoring executed in workspace A can be "reapplied" on workspace B to refactor any remaining references to the refactored element. Furthermore, existing refactorings will be improved to preserve API compatibility where possible (for example when renaming a method, a deprecated stub with the old signature will be generated that forwards to the new method). [JDT Core/UI] (106207) [Theme: Scaling Up].
API-aware tools. Given the importance that the Eclipse community places on stable, robust APIs, having good support for their implementation is critical. The support within Eclipse for describing APIs should be improved, along with better tools from assisting developers to stick to APIs provided by other plug-ins. [PDE, JDT] (106213) [Theme: Enterprise Ready]
Improve PDE build. PDE Build is fundamental to how the Eclipse Platform releases are produced. It is also increasingly being used by other Eclipse projects and in the wider community. Potential improvements to PDE build include parallel cross-building, incremental building of plug-ins, increased integration with the workspace model, and support for additional repository providers. [PDE] (106214) 106214[Theme: Enterprise Ready]
There's a log more to read, and there is the link on the page to API change tracking. If they deliver most or all of what is targeted (and not just my interest list), then Eclipse 3.2 is going to be a powerful challenger. It will be interesting to see how NetBeans responds.
Comments
Post a Comment
All comments are checked. Comment SPAM will be blocked and deleted.