Skip to main content
Jump to: navigation, search

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

< PDE‎ | API Tools
(New page: Integration of Use and Migration Scans {bug|310547} 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'r...)
 
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
Integration of Use and Migration Scans
+
{{bug2|310547|Support usage scanning tools in IDE}}
{bug|310547}
+
  
 
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
provide scans back to you on what API and internal code they're using. As far
+
provide scans back to you on what API and internal code they're using. The tooling
as I can tell, these tools are currently command-line and there is no support
+
is ant task based.  What we want is integration into the IDE so a scan can be loaded and
for using the reports within the IDE.
+
any breaking changes will be marked as problems in the editor.
 
+
I'm opening this enhancement to request IDE support - being able to point to a
+
number of scans, have it show you which classes and methods are being used, and
+
the ability to flag errors when usage is broken (i.e. when you don't want to
+
break adopters within a service release, no matter how much internal code they
+
used).
+
  
 
= Main Components =
 
= Main Components =
  
== UI for managing scans ==
+
=== UI for managing scans ===
- Preference page
+
* Preference page
  
== Backend for managing scans ==
+
=== Backend for managing scans ===
- Store in metadata?
+
* Store in metadata?
- Needs to be more efficient than separate xml files
+
* Needs to be more efficient than separate xml files
  
== Incremental Builder ==
+
=== Incremental Builder ===
- Add to the existing API Tooling incremental builder
+
* Add to the existing API Tooling incremental builder
- Compare current type against use scan and return breakage
+
* Compare current type against use scan and return breakage
  
== Marker Management ==  
+
=== Marker Management ===
- Create markers for usage breaking changes
+
* Create markers for usage breaking changes
- Clean stale markers when content or use scans change
+
* Clean stale markers when content or use scans change
- Needs new error level settings
+
* Needs new error level settings
  
== Performance ==
+
=== Performance ===
- Must have no impact when off (check error level settings at start)
+
* Must have no impact when off (check error level settings at start)
- Use LRU caches as scan cannot be loaded into memory
+
* Use LRU caches as scan cannot be loaded into memory
- Full builds must be possible
+
* Full builds must be possible
  
== Tests ==
+
=== Tests ===
- Complete test suite for incremental builder
+
* Complete test suite for incremental builder
- Enhance the performance tests
+
* Enhance the performance tests
  
 
= Additional Enhancements =
 
= Additional Enhancements =
  
== Annotate method/type usage in editors ==  
+
=== Annotate method/type usage in editors ===  
- When editor is open, methods/types being used are annotated
+
* 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
  
== Support multiple scans ==
+
= Implementation Ideas =
- Compare against all of them
+
  
== Use Scan Updating ==
+
* 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:
- Support for recognizing when a newer use scan is available
+
** 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.