Skip to main content
Jump to: navigation, search

Difference between revisions of "PDE/API Tools/Migration IDE Integration"

< PDE‎ | API Tools
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{bug2|310547}}
+
{{bug2|310547|Support usage scanning tools in IDE}}
  
 
The 3.6 API tools have support for usage scanning - allowing adopters to
 
The 3.6 API tools have support for usage scanning - allowing adopters to
Line 43: Line 43:
 
=== Use Scan Updating ===
 
=== Use Scan Updating ===
 
* Support for recognizing when a newer use scan is available
 
* Support for recognizing when a newer use scan is available
 +
 +
= Implementation Ideas =
 +
 +
* Consider a Java builder participant - we are really only looking up types in the new description, which we can easily do during the participant cycle. Some of the benefits of this approach:
 +
** No impact at all on the API builder
 +
** marker support + lifecycle from the Java builder
 +
* Examine how Java access rules work + are stored + looked up. Perhaps there is opportunity there for us to extend an access rule and get UI + persistence for free
 +
* Examine XPath and related technologies for fast indexing / searching of XML file(s) to avoid loading (potentially) massive files into memory all at once

Latest revision as of 11:48, 30 September 2010

Bug.png
310547
Support usage scanning tools in IDE


The 3.6 API tools have support for usage scanning - allowing adopters to provide scans back to you on what API and internal code they're using. The tooling is ant task based. What we want is integration into the IDE so a scan can be loaded and any breaking changes will be marked as problems in the editor.

Main Components

UI for managing scans

  • Preference page

Backend for managing scans

  • Store in metadata?
  • Needs to be more efficient than separate xml files

Incremental Builder

  • Add to the existing API Tooling incremental builder
  • Compare current type against use scan and return breakage

Marker Management

  • Create markers for usage breaking changes
  • Clean stale markers when content or use scans change
  • Needs new error level settings

Performance

  • Must have no impact when off (check error level settings at start)
  • Use LRU caches as scan cannot be loaded into memory
  • Full builds must be possible

Tests

  • Complete test suite for incremental builder
  • Enhance the performance tests

Additional Enhancements

Annotate method/type usage in editors

  • When editor is open, methods/types being used are annotated

Support multiple scans

  • Compare against all of them

Use Scan Updating

  • Support for recognizing when a newer use scan is available

Implementation Ideas

  • Consider a Java builder participant - we are really only looking up types in the new description, which we can easily do during the participant cycle. Some of the benefits of this approach:
    • No impact at all on the API builder
    • marker support + lifecycle from the Java builder
  • Examine how Java access rules work + are stored + looked up. Perhaps there is opportunity there for us to extend an access rule and get UI + persistence for free
  • Examine XPath and related technologies for fast indexing / searching of XML file(s) to avoid loading (potentially) massive files into memory all at once

Copyright © Eclipse Foundation, Inc. All Rights Reserved.