|
Last revised: 2008/08/27
This plan is under continuous refinement. Please send comments about this plan to the pde-ui-dev@eclipse.org developer mailing list.
Overall Goals
This section lists the goals for Eclipse 3.5 for the PDE/API Tools component as listed on the
Eclipse Project 3.5 Draft Plan.
[1] Performance.
Monitor overall performance and memory consumption. Build a new performance test suite.
[2] Reliability.
Build a comprehensive regression test suite for the API Tools builder. Fix critical bugs, provide APIs as required.
[3] Keep Eclipse vibrant and attractive.
Investigate and implement enhancements such validating system library access based on a project's associated execution environment. |
Milestone M1 (2008-08-08)
|
 General Items [2]
 3.4.1 maintenance work- Bug fixing
|
Milestone M2 (2008-09-19)
|
General Items [2]
- 3.4.1 maintenance work
 Bug fixing
Reliability [2]
- Build a comprehensive regression test suite for the API analysis builder (Michael Rennie, Darin Wright, IBM) [bug 218571]
- >[M3] Build a performance test suite (Michael Rennie, Darin Wright, IBM) [bug 245434]
- Publish a Smoke Test plan on the web (Michael Rennie, IBM) [bug 245415]
Usability/Workflow [3]
- Polish API Errors/Warnings preference page (Olivier Thomann, IBM)
- Reduce the number of settings by combining errors related to type variables/bounds into one section and combining type conversions into one error [bug 242618 and bug 242610]
- Simplify settings for Annotations [bug 242609]
Testing |
Milestone M3 (2008-10-31)
|
Architecture/Infrastructure [3, 1]
- Migrate architecture to support binary or source analysis
- Consolidate data structures used for delta creation and API use/leak analysis
- Make search criteria implementation more flexible by allowing specializations rather than having one search criteria that can do everything
 Investigate integration as Java compilaion participant
- > decided not to follow this path in 3.5 - compilation participants are intended for lightweight function
API Analysis Enhancements [3]
- For non-API super-type leaks, analyze if anything internal is actually exposed
- Allow "friends" to have special privileges - like implement, reference etc.
- > decided not to implement this feature (not that widely used - indicates implementation is split across several bundles)
- >[deferred to M4] Flag when new API is used in a required bundle that requires the version range to be incremented/updated (i.e. using a new API, so lower bound needs updating)
Testing [2, 1]
- Build a performance test suite (Michael Rennie, Darin Wright, IBM) [bug 245434]
|
Milestone M4 (2008-12-12)
|
System Library access validation [3]
- Validate references to system library based on EE (J2SE-1.4, etc). A 1.4 project should not reference 1.5/1.6 methods/classes
- Investigate methods to ship required metadata for access validation
RelEng Ant Task API [2]
- Support API ant tasks for general consumption and integration into RelEng build process
- Separate data collection and report generation such that report generation can be pluggable
- Document use of the Ant tasks in ISV guide
API Analysis Enhancements [3]
- >[from M3] Flag when new API is used in a required bundle that requires the version range to be incremented/updated (i.e. using a new API, so lower bound needs updating
- Enhance API use analysis to process anonymous/local types [bug 246672]
- Support @noextend tag on interfaces, in addition to @noimplement [bug 230189]
- Tooling to clean up stale API problem filters [bug 244676]
Baseline Definition [2]
- Follow PDE's use of p2 to discover/analyze what bundles are present in an installation
- API Baseline definition is similar to target platform definition, and we should use a similar approach
Testing
- Create incremental build performance tests [bug 251617]
|
Milestone M5 (2009-01-30)
Major/Big Features Done
|
Extension point compatibility analysis [3]
 Analyze extension points for compatibility errors (addition of non-optional attributes) - Update bundle version numbers based on breaking/compatible changes in extension points
API Analysis Enhancements [3]
- [>from M4] Flag when new API is used in a required bundle that requires the version range to be incremented/updated (i.e. using a new API, so lower bound needs updating)
- Support to handle plug-in split/re-organization properly during compatibility analysis [bug 240914]
- Support to handle fragments properly during compatibility analysis [bug 255720]
- [> M6] Improve presentation of API tooling reports in the releng build
- [> M6] Code assist should filter system library completions [bug 256287]
API comparison reporting [3]
- [> M6] Tooling to compare APIs - highlights what APIs have changed in a release, relative to a baseline
- Could be presented in the IDE (structural compare)
API use reporting [3]
 [> M6] Tooling to identify what clients (plug-ins/bundles) are illegally using non-API code
- Note that this is different from current discouraged access reporting, since it allows the producer to see who is accessing their code, rather than flagging the consumer with a problem
- Could be presented in the IDE (search) and as an Ant task/report for RelEng build
Baseline Definition [2]
- [> M6] Follow PDE's use of p2 to discover/analyze what bundles are present in an installation
- API Baseline definition is similar to target platform definition, and we should use a similar approach
Testing
- >[from M4] Create incremental build performance tests [bug 251617]
|
Milestone M6 (2009-03-13)
API Freeze
|
API Use Reports [3]
- [> from M5] Generate producer centric report of what API/non-API is being consumed by other bundles [bug 259403]
Baseline Definition [2]
- [> from M4] Follow PDE's use of p2 to discover/analyze what bundles are present in an installation
[bug 239493]
- API Baseline definition is similar to target platform definition, and we should use a similar approach
API Comparison Reporting [3]
- [> from M5] Generate API comparison report - highlights what APIs have changed in a release, relative to a baseline [bug 258853]
- [>from M4] Detect when new API is used in a required bundle that requires the version range to be incremented/updated [bug 255771]
Performance
- Tune incremental build performance tests [bug 260732]
Polish
- [> from M5] Support to handle plug-in split/re-organization properly during compatibility analysis [bug 259997]
- Include API descriptions when exporting plug-ins from the workspace [bug 227202]
- [> from M5] Improve presentation of API tooling reports in the releng build [bug 257724]
- [> from M5] Code assist should filter system library completions [bug 256287]
Testing |
Milestone M7 (2009-05-01)
Feature Freeze, Focus on Performance and Polish
|
Performance
- Improve incremental build performance and footprint [bug 233643]
Polish
Testing |
