Do not take into account fields that doesn't affect IDE
Also it will threat configurations from old and new scripting API as similar
FIt will make sense for script dependencies loaded using Gradle TAPI (new Scripting API) and Old Scripting API
^KT-34626
Listen to changes in files that may affect gradle configuration
Remove configuration request if none of such file was changed since last request
^KT-34442 Fixed
It was missing during configuration refinement thought new scripting API and during loading script configuration on Gradle project import
Do not pass additional classpath to configuration classpath: this may only affects Gradle with New scripting API (because it isn't used from other places)
In additional classpath kotlin-compiler and kotlin-stdlib was passed and there is no needs for this during loading Script Definitions through new scripting API
^KT-34626 Fixed
We have plans to extract separate implementation for Gradle scripts, but it
would be better to support something at this point.
For now, we have custom listener, loader and up-to-date check for default configuration manager:
- listener will do forced reload on editor activation, even it is already up-to-date
this is required for Gradle scripts, since it's classpath may depend on other files (`.properties` for example)
- loader will force save failures before running loader. also it will skip loading if
`kotlin.gradle.scripts.useIdeaProjectImport` registry key is enabled
- loader will return inputs with overridden up-to-date checks: file will be considered
out-of-date only when `buildscript` or `plugins` blocks are changed
## Simplify ScriptConfigurationManager mental model
Everything related to cache managing moved to `org.jetbrains.kotlin.idea.core.script.configuration`.
DefaultScriptConfigurationManager slitted into:
- `AbstractScriptConfigurationManager`
- `DefaultScriptConfigurationManager`
- `ScriptClassRootsCache`
The main idea is to simplify the mental model of ScriptConfigurationManager.
Concrete implementation should provide just two things:
- `createCache(): ScriptConfigurationCache` that should return cache implementation with `get` and `set` methods
- `reloadOutOfDateConfiguration(...)` will be called on [cache] miss or when [file] is changed.
Implementation should initiate loading of [file]'s script configuration and call [saveChangedConfiguration]
immediately or in some future (e.g. after user will click "apply context" or/and configuration will be
calculated by some background thread).
Everything around it is implemented in `AbstractScriptConfigurationManager`.
`ScriptClassRootsCache` is extracted from `DefaultScriptConfigurationManager`:
this simplifies `AbstractScriptConfigurationManager`
Also it simplifies ScriptClassRootsCache reset: we can just drop old `ScriptClassRootsCache`
and create new one instead of resetting all internals of `ScriptClassRootsCache`.
Please see KDoc of these classes for more details:
- AbstractScriptConfigurationManager
- DefaultScriptConfigurationManager
- ScriptClassRootsCache
## Cache and up-to-date checks
Writer should put related inputs snapshot for loaded configuration.
This allows reader make up-to-date check for existed entry to avoid starting loading
process for same inputs.
Cache entry may be marked out-of-date.
Also it can be marked up-to-date, but it means that we have up-to-date loaded configuration,
ScriptConfigurationSnapshot.configuration will still contain old applied configuration.
todo: make it more clear by splitting cache entry into loaded and applied configuration with
it's own inputs.
## Loaders
Previously both sync and background loaders may be started for same files - this was useful, but not
required anymore and at the same time greatly complicates the model. So, it was dropped
and now exactly one loader should work for given file (first applicable loader will be called).
Also `ScriptConfigurationLoadingContext` is introduced to limit access to the `ScriptConfigurationManager`
internals.
## Listeners and updating configuration
This things is introduces:
- `ScriptChangesNotifier`
- `ScriptChangeListener`
- `ScriptConfigurationUpdater`
`ScriptChangesNotifier` will call first applicable `ScriptChangeListener` when editor is activated or document changed.
(it treated as applicable if [editorActivated] or [documentChanged] will return true).
Listener may call [ScriptConfigurationUpdater] to invalidate configuration and schedule reloading.
Plugins may override default listening logic by adding it's oven `ScriptChangeListener`.
`ScriptConfigurationUpdater` was extracted from `ScriptConfigurationManagerImpl`.
## Fixed issues and implement persistent FS cache
- Script configuration was not reloaded if query for same file already in progress or ready but not yet applied
- Don't start async loaders for outsider files
- Unused imports: don't start loading script configuration if the result will be not applied automatically
- Fix cases when virtual file can be null
See `DefaultScriptConfigurationManager.reloadOutOfDateConfiguration` KDoc for more details on
dealing with concurrent operations.
## Background executor and progress indicator
This things changed and fixed:
- progress displayed not only when we have more then 3 loading tasks, but also
after 1sec of loading (including case with 1 loading task for example)
- current file is displayed under the progress bar
- progress indication added: it works similar to indexing indicator. When
progress bar is displayed, max is fixed. When all work done for this max,
progress will be started from zero and new max is fixed, and so on
- cancel will drop all loading operation, not just current
- concurrency issues fixed: EA-5244265 and other related to switching between silent and
under progress worker
See `BackgroundExecutor` for more details.
## Gradle specific behavior
We have plans to extract separate implementation for Gradle scripts, but it
would be better to support something at this point.
For now, we have custom listener, loader and up-to-date check for default configuration manager:
- listener will do forced reload on editor activation, even it is already up-to-date
this is required for Gradle scripts, since it's classpath may depend on other files (`.properties` for example)
- loader will force save fails before running loader. also it will skip loading if
`kotlin.gradle.scripts.useIdeaProjectImport` registry key is enabled
- loader will return inputs with overridden up-to-date checks: file will be considered
out-of-date only when `buildscript` or `plugins` blocks are changed
Sergey Rostov