Remove customized data providers from manager

[bhufmann]

What it does

Remove any instances of derived data providers and sub-data providers created with InAndAnalysis.

fixes #178

Requires the following Trace Compass PRs:

• tmf: Add API to remove data provider instance from dp manager eclipse-tracecompass/org.eclipse.tracecompass#254
• tmf: Exit loop only when match was found when removing data provider eclipse-tracecompass/org.eclipse.tracecompass#256
• tmf: Add API DataProviderManager.getAvailableProviders(trace, config) eclipse-tracecompass/org.eclipse.tracecompass#257

How to test

1. Create custom InAndOut using tsp-python-client
2. Open InAndOut call stack view from vscode-trace-extension
3. Delete custom InAndOut using tsp-python-client
4. Re-create same custom InAndOut as in 1)
5. Open InAndOut call stack view from vscode-trace-extension
6. The view is not empty

Note: The same issue exists for the 3 other derived views and it is fixed with this PR.

Follow-ups

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the instructions in this template

Signed-off-by: Bernd Hufmann [email protected]

[PatrickTasse]

Yes, I like this implementation a lot better. But I can't help but think that this would need to be done by all factories that support configurations. It could have been the new API in DataProviderManager: removeProviders(ITmfTrace, ITmfConfiguration), that would remove all data providers that have this configuration, instead of per data provider id.

I also wonder if, in this implementation, the first call to the method would also cover the removal of the data provider that is being explicitly removed by the DataProviderService in the previous commit.

So I'm thinking, in DataProviderService.deleteDerivedProvider(), could it just call something like DataProviderManager.removeProviders(ITmfTrace, ITmfConfiguration), and then the configurators/factories only need to worry about removing the descriptor and configuration? They are not really the owners of the data provider instances.

One consideration is that either DataProviderService or DataProviderManager would need to do this processing for the full trace set (experiment and its child traces).

[bhufmann]

Interesting comment. It's the same idea than for the first commit, but it would take care of all sub data providers. I'll try it. It requires another change in mainline TC.

[bhufmann]

I created eclipse-tracecompass/org.eclipse.tracecompass#257 and apply in this PR.