Comments on "Frallax feedback"#1
Conversation
| * the | ||
| * @throws TmfConfigurationException if an error occurs | ||
| */ | ||
| public static void remove(ITmfConfiguration config, @NonNull ITmfTrace trace, String baseAnalysisId) throws TmfConfigurationException { |
There was a problem hiding this comment.
create() and remove() includes how the analysis module is initialized and how the configuration file is managed. But we're writing config files in our own specified location (per data provider id), so those are preferably in our own code?
There was a problem hiding this comment.
And if we move create() and remove() to internal code, AbstractTmfDataProviderConfigurator.traceOpened() and TmfConfiguration.readConfigurations() also needs to be in internal code, because we no longer have control over where we store the files.
| */ | ||
| module.setConfiguration(config); | ||
| if (writeConfig) { | ||
| IPath traceConfigPath = TmfConfiguration.getConfigurationRootFolder(trace, config.getSourceTypeId()); |
There was a problem hiding this comment.
Here we can't store it per config.getSourceTypeId() as it'll cause conflict when different data providers are using the same config source type id.
| module.setConfiguration(config); | ||
| if (writeConfig) { | ||
| IPath traceConfigPath = TmfConfiguration.getConfigurationRootFolder(trace, config.getSourceTypeId()); | ||
| TmfConfiguration.writeConfiguration(config, traceConfigPath); |
There was a problem hiding this comment.
Also here we'll be writing a configuration to file whenever we create an analysis module, which is still binding one configuration file to one analysis module. So the configuration on data provider level will still needs to be a parallel implementation. Which means we'll be writing configuration to file in different places in the code.
2 participants
This is a direct copy of branch "frallax-config-refactor" to write comments.