The embedded frontend launcher in PyCharm Community already has the proper pathsSelector, so an attempt to fix it will replace 'PyCharmCE' by 'PyCharmCECE'.
GitOrigin-RevId: dfba27a2316c9934a8b6bfa3025909a88731ffa7
We use the same distribution of the frontend part for community and ultimate/professional editions of IntelliJ IDEA and PyCharm, and 'idea.path.selector' property is set to the value from the ultimate/professional edition. To use proper value when connecting to a backend from the community edition, we need to adjust it based on the product code specified in the join link in the command line arguments.
GitOrigin-RevId: 663f40075eef089d7a8e36ec0ee2a8ba5f39af10
Since it's used for the frontend process only, the check for the mode isn't needed anymore. However, we still need to support a 'generic' variant of the frontend which isn't built for a specific IDE and therefore needs to use a 'JetBrainsClient' prefix for directory names.
GitOrigin-RevId: be52b1a8d32c2e63fe6d90a279e93209a07b2f43
This is needed for clarity, since we have a separate P3PathCustomizer now. The common code which was reused by P3PathCustomizer is moved to a separate PerProcessPathCustomization class.
GitOrigin-RevId: bee9775ff2f5790239a6c1b55283ffbadb11f39f
If the frontend process uses the same 'idea.paths.selector' as the monolithic IDE, it's better to put its temporary config and system directories under a special 'frontend' folder. This way they won't be mixed with other per-process folders, and we can be sure that they won't be cleared by the monolithic IDE while the frontend process is running.
GitOrigin-RevId: 5662f7fce327bd5c4d38a829d21d420caee63777
'intellij.platform.bootstrap.coroutine' module provides a custom variant of DebugProbesKt class from kotlin-stdlib, so it should come first in the classpath to ensure that coroutines dumps work if the IDE or tests are started without packing modules to JARs and without explicitly specified coroutines agent.
GitOrigin-RevId: 2751c8052f3c0285ad109d67daa1d3eb0e7ddb10
If the frontend process uses the same config directory as the corresponding local IDE, there is no need to customize where it imports settings from, the default behavior should work well. However, we still need to store plugins for the local IDE and the frontend variant separately, because not all plugins are compatible with both variants, and we currently cannot determine compatibility while loading plugins. So plugins for the frontend variant are stored in ${idea.plugins.path}/frontend directory.
It isn't enough to migrate plugins from the local IDE to the frontend during migration of the settings. It may happen that the local IDE of this major version was already run on this machine, so when the frontend is started, the config directory will exist and no importing will be performed. To initiate migration of plugins in that case, PerProcessPathCustomizer manually initiates config importing if the plugins directory doesn't exist.
Also, it may happen that the frontend process performs the initial config importing. In that case, it also migrates the plugins for the local IDE from the previous version, because when the local IDE will be started for the first time, the config directory will exist and no importing will be performed.
GitOrigin-RevId: 9dae5c03001b45240e6ae3bbaa56224b522de2f4
We use the same root JetBrainsClientPlugin.xml for all IDE-specific frontends, and not all product content modules specified in it are available in all IDEs. E.g., 'intellij.notebooks.ui' isn't present in CLion. Since content modules are optional, absence of some of the in the distribution shouldn't cause an error.
GitOrigin-RevId: 074f93d1a5c31de6d6bf5152d96ba150c72bf7b2
The frontend part of the IDE has its own list of content modules, and at least one of them ('intellij.cwm.guest.notebooks') is not included in lib/modules directory, and it's not simple to put it there, because it's currently part of CWM plugin distribution. So 'findProductContentModuleClassesRoot' is introduced in 'ProductLoadingStrategy', which computes path to the classes root of the module using data from the module repository if the module-based loader is used.
GitOrigin-RevId: dddcb8b16dce64fd73a0cbdde507daaa5b069a10
To find and report native crashes `PerformanceWatcherImpl` requires two files: `.pid` and `.appinfo`
These files are stored in the system directory (`PathManager.getSystemPath()`).
For JetBrainsClient we replace default system path (`JetBrains/IntelliJIdea[VERSION]`) with custom per process path (`JetBrains/JetBrainsClient[VERSION]/tmp/per_process_system_0`)
This custom directory is cleaned up on every start therefore `.pid` and `.appinfo` files are also deleted and `PerformanceWatcherImpl` cannot send crash reports.
To fix that, we now keep these files between client restarts.
GitOrigin-RevId: 7c50445d07767cc3a12e36c5511778235e8142b6
Rename PerProcess to P3 (Project Per process)
open different projects in different processes if perProcess mode is enabled
GitOrigin-RevId: cd44340f0cca0caad8f5bac0882978735e0e2e17
Disable AntiFlickeringPanel that wraps the debugger tree to reduce flickering and proxies the primitives into a big image
GitOrigin-RevId: 42cac5be81df9a1ea839f6d64abe8f779f6dcdee
Modules defined in 'content' tag in plugin.xml may have dependencies on other modules which aren't included in the platform part or other plugin (e.g. 'intellij.terminal' depends on 'intellij.terminal.completion'). Before only dependencies on libraries were supported. Now ServiceModuleMapping collects all such dependencies and associates them with corresponding plugin module groups, so they are added to the plugin classloaders.
GitOrigin-RevId: 772763ba8834f0306475c5666eadbf0de0e47e00
ProductLoadingStrategy.currentModeId is added. For module-based implementation which is currently used for JetBrains Client, it returns the value explicitly passed via a system property. For path-based implementation, which is currently used for local IDE and backend, the value is computed manually depending on command line arguments.
GitOrigin-RevId: 4a61eaef60febcf3e6d086b8e6eb68fcf2b935ef
ProductModules and related API aren't needed for the initial startup procedure in IntellijLoader, they are used later from ProductLoadingStrategy. So they are now moved from 'intellij.platform.runtime.repository' module to a new 'intellij.platform.runtime.product' module. This reduces the amount of code located in platform-loader.jar included in the initial classpath. Also, it allows to use code from other modules and libraries in the implementation of ProductModules (e.g., write code in Kotlin).
GitOrigin-RevId: 86bbab20f217b91104df20d546dc6bda376fb63c
