This is needed to speed up generation of the runtime module repository for a real distribution and for dev build in the build scripts.
IJ-MR-174028
GitOrigin-RevId: 5f1117262af8515b2e63b5b3a8d0ace0c102f6fd
Before it analyzed transitive dependencies of each module separately to produce runtime descriptors for their test parts. Now results for different modules are cached and reused. In total, this reduces generation time by 7 times (from 3 seconds to 400ms for the intellij ultimate monorepo on my machine).
As a result, some transitive dependencies for test modules aren't included as direct dependencies anymore, but this shouldn't affect behavior at runtime.
IJ-MR-174028
GitOrigin-RevId: 51f5fe3d08eac12e9a33d00865db73e74b4b79fe
If the JPS build doesn't generate the runtime module repository, we need to produce it in build scripts from scratch. It will be more efficient and convenient to generate it with proper resource paths for modules and libraries directly instead of first generating it with JPS output paths and then replacing the paths.
GitOrigin-RevId: 3c57f41ba719857be1a15032747dc5ae5bddb629
This commit enables check only for modules WITH a Kotlin facet
Bazel generator was updated as well
GitOrigin-RevId: 90a3427d4b5a3ebc29e257693cb3748ac09bfc6a
This is needed to reuse the generator in the build scripts without adding a dependency on PathRelativizer from the JPS build.
GitOrigin-RevId: 112ac4aa3cf5c2833d9a89e4db0d98169ba6bc2f
Currently, the runtime module repository is generated by a plugin inside the JPS build during compilation. Doing the same in Bazel doesn't look like a good option because generating something for all modules in the project contradicts the incremental nature of Bazel. So it's better to invoke generation of the runtime module repository by JPS project configuration inside build scripts. To do that and avoid having dependencies on the JPS build classes inside the build scripts, the code which generates the runtime module repository is moved to a separate module 'intellij.devkit.runtimeModuleRepository.generator'.
GitOrigin-RevId: f2596fd51c1c019d304de36ed93fe163cf519ae6
A new implementation which generates and loads the runtime module repository from a module-descriptors.dat file in binary format is implemented. module-descriptors.jar in the old format is still generated for compatibility with other tools (e.g., IntelliJ Platform Gradle Plugin) and to provide a human-readable view. It's also used as a fallback variant if module-descriptors.dat is absent.
The new format speeds up loading by around 10 times.
GitOrigin-RevId: b17ba7b53f825e6dcf243ff0aa5b7aedaf7ab9e2
Otherwise, dependency from 'intellij.maven.ultimate.testFramework' module to 'intellij.idea.ultimate.tests.main' breaks the generation of the module repository: the latter is considered as a test-only module, so a descriptor for its production part isn't generated, but the production part of the former has a dependency on it. It's possible to fix this by using 'test' scope for such dependencies or by adding more exceptions in 'isTestOnly' check, but it's not reliable. Given that we already have the problems with 'isTestOnly' heuristics in the past, it's better to get rid of it. This results in about 200 more descriptors created for IntelliJ Ultimate project, but this shouldn't be a problem especially when we start using more compact storage for the runtime module repository.
GitOrigin-RevId: 613c5d4a55ae853e774ded31a4ab5345646ac2e9
Even if the name of the module satisfies 'isTestOnly' conditions, we still need to generate a descriptor for it if it has production sources. Recently, a new module 'intellij.rdct.tests.plugin' was added, which satisfies the condition, and at the same time the test which checks that no modules satisfying 'isTestOnly' condition have production sources was modified (see 39890e67352a1889). So the descriptor wasn't generated for the module, and build scripts fail it in FrontendModuleFilter.isModuleCompatibleWithFrontend.
GitOrigin-RevId: 2814a470f4825449c21adf5bc013c01bfd3f948b
This is needed to support loading the module repository from multiple JAR files, which is in turn needed to support non-bundled plugins (IJPL-633).
GitOrigin-RevId: 853ed4f3221cb2aa34696802d6c36f9636da97b6
Code which adds transitive dependencies for tests is modified to include only those dependencies which aren't already available. This change reduces the size of module-descriptors.jar from 4.2Mb to 2.2Mb for the intellij ultimate project.
GitOrigin-RevId: f1ac6cd72b082afac5a8d3100c8664dbbe80fbe0
The runtime module descriptors file should be updated if and only if something changes in the configuration of modules and libraries. Since up-to-date checks in org.jetbrains.jps.incremental.BuildOperations are based on files, we need to have at least one source file registered by the builder for that. Here .idea/modules.xml is used for that.
GitOrigin-RevId: ca5e56dfca75d63e4056017a4164dd3fbb20b116
Currently com.intellij.platform.runtime.loader.Loader parses all module descriptor xml files to compute classpath for ModularMain class, this may take noticeable time. Now classpath for the bootstrap module is cached in an attribute of MANIFEST.MF file, so it can be loaded faster. This is done for production mode only, because in that mode paths to classes roots don't use macros, so there is no need to substitute them.
GitOrigin-RevId: 0af716f718976b67c3a6bcfc94358a0b488d8649
Module descriptors are put to a separate module-descriptors.jar now, and we don't plan to place their resources to that JAR, so the paths will always start with '../' prefix, and it'll just complicate code and requires additional work at runtime. So let's suppose that paths in module-descriptors.jar are relative to the directory where the JAR file is located.
GitOrigin-RevId: 43572247998686fd81d66bcdfba8dd700605281b
Unresolved dependencies don't always indicate a real problem, because they may correspond to optional dependencies from bundled to non-bundled plugins. So instead of checking this in the build scripts, it's better to check this in a test.
GitOrigin-RevId: dfe404cbbfe27ee41733cf46f0f0926e37ce3c12
This change introduces RuntimeModuleRepository API which will be used to determine paths to classes and other resources of modules at runtime. It also adds RuntimeModuleRepositoryBuilder which generates descriptors for modules during compilation of intellij project (this is controlled by a registry key which is switched off by default for now).
GitOrigin-RevId: be33235ec0cdb7ea55a925e753b9b58a3ca63ac3
