Community
Participate
Working Groups
There needs to be a way to flag an individual non-API reference so that the apitooling.apiuse task will treat it differently. The task either should not report the reference at all, or should report in a different way so that it is kept separate from the unflagged references. The use case for this feature is as follows: Assume that I own a bunch of bundles that have dependencies on Eclipse Platform and other Eclipse stuff. I run the apitooling.apiuse task over my bundles to identify any non-API stuff that I am using. Once I have the list of non-API references, I set out to fix them. Some of them can probably be fixed quickly, but others may take some time. For example, I may need to file a bug against Eclipse Platform to get them to create new API to do what my bundles need. While I am waiting for the dependent bundles to add new API, I want to continue to run apitooling.apiuse on a regular basis so it will flag any newly added non-API references that creep into my code. But I don't want it to flag the non-API references that are in the process of getting fixed. I already know about those.
There are two components to this bug: 1) Filter list We need to define a file structure (either xml or properties file) that can list the filters. The tasks should support different levels of filtering (packages, bundles, types, regex, etc). The exact granularity required is still being discussed. 2) Tooling to create filters The filter file should be human readable, but crafting it by hand is likely too onerous for clients. We should provide a tool (view, editor, wizard) to mkae crafting a list of filters easier. Currently we believe that a tree viewer where the user can mark or drag'n'drop different items into the filter list will be the most practical. We would also provide the ability to see what filters currently existed, allowing for deletion or manually crafting a filter. We might also provide a way to test out the filtering and see what results show up.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant please remove the stalebug whiteboard tag.
