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 |