Community
Participate
Working Groups
JDT CodeMining provides debug and JUnit code mining providers. Those kind of providers requires to update code minings by calling "ISourceViewerExtension5#updateCodeMinings()" to update their informations: * in debug when stack frame changed-> https://github.com/angelozerr/jdt-codemining/blob/master/org.eclipse.jdt.codemining/src/org/eclipse/debug/ui/codemining/provisional/AbstractDebugVariableCodeMiningProvider.java#L81 * in JUnit when test is finished-> https://github.com/angelozerr/jdt-codemining/blob/master/org.eclipse.jdt.codemining/src/org/eclipse/jdt/experimental/junit/codemining/JUnitCodeMiningProvider.java#L36 The call of ISourceViewerExtension5#updateCodeMinings() means that ALL code minings providers are reevaluated although we should just update the well provider (debug or JUnit). This feature requires a new API to update code minings. Perhaps we could use the same API for https://bugs.eclipse.org/bugs/show_bug.cgi?id=541317 ?
I don't think this API is so necessary; and instead we should identify and establish some good practices for code mining providers to work together. Indeed, we have here the case of some providers reacting to text change/reconcilier event and some other reacting to debug session events. There is nothing AFAIK that prevents a codeminingprovider from caching it's last results and reusing them when requested if no relevant change took place. For example, the reference code codeminingprovider doesn't have to re-compute the codeminings when debug session change, it could just return the previous one by looking at the last change in the text. This can be done internally in the codeminingprovider without an API.
