We have code that invokes `jpsLibrary.getParent().getParent()` to get a JpsModule instance for a module-level library. To keep such code working, we need to have JpsModule and JpsProject as super-parents (not direct parents) of JpsLibrary instances in the new implementation as well.
GitOrigin-RevId: a5f944d152229275b05efdfc686afa091c3fd963
StorageSerializerUtil.getVirtualFileUrlSerializer stores VirtualFileUrl instance in completely different format if 'ide.workspace.model.store.relative.paths.in.cache' registry option is enabled. Deserialization in the build process must use the same format as the IDE, so now value of this registry options is passed as 'ide.workspace.model.store.relative.paths.in.cache' system property to the JPS build process and used there to switch relativization on or off.
GitOrigin-RevId: a87b7f4f1a2c073a8d1fdaaa72a38b5dc11d0e01
Otherwise, next tests will store application-level data in the temporary directory instead of using PathManager.getConfigPath, causing failures (e.g. PluginModuleCompilationTest).
GitOrigin-RevId: ee74f364b1d718b9cfa89a4e49f2b0e405189647
The method always returned 'false'. It doesn't make sense to improve this given that the JPS model is being migrated to Workspace Model (IJPL-409).
GitOrigin-RevId: ab8ef8486227e51e19a0028fe171ad44de73cca0
The previous project model collected roots grouped by the root type. Because the order of keys doesn't exist in maps, the `iml` save sorted the groups alphabetically. And after the `iml` was loaded, this sorting didn't affect the library itself.
In case of `LibraryEntity`, the roots are stored in the flat list, so such sorting will cause `LibraryEntity` change. With an additional logic, we'll avoid an extra "roots changed" event
GitOrigin-RevId: b82823dd5b1a2a266bdda73b65ef51af6c4f5f24
JpsModuleReferenceImpl and JpsLibraryReferenceImpl won't resolve if the new implementation is used, so parts of JpsModel which aren't converted to use the workspace model, also need to use *Bridge implementations.
GitOrigin-RevId: 25eb3336d29457ae0c735d74e42960e87cc89b49
JpsModuleExtensionBridge API is introduced which allows converting child entities of ModuleEntity in the workspace model to child elements of JpsModule in the build process.
GitOrigin-RevId: 86277abed01980441b40f7eec3bcd16ca57e040f
This is needed to move the latter to to intellij.platform.workspace.jps module to reuse it in the JPS build process (IJPL-409).
GitOrigin-RevId: 128a318e9f36a7efa06cc1dc3dcbded8212f0ccc
Unlike the old implementation, the new one may call JpsComponentLoader.loadComponent multiple times for the same file, so it's better to cache content to speed up loading.
GitOrigin-RevId: 4c3630f24bdcb8740ef5cd3ba6d414febb0f9d77
The workspace model uses configurationStore API to load data, and there attributes of the root tag are represented as options in an artificial DeprecatedModuleOptionManager component.
GitOrigin-RevId: 2a0a197e8f41c491d5b9ffd9f707a9e2315f1301
Data which is present in the workspace model is taken from it, other components are loaded from xml files as before.
GitOrigin-RevId: 368e2b15aa055bc3489fb944c334379f10f2725e
And fix cases where null was actually passed. Before, it was easy to forget to check it for null in the implementations.
GitOrigin-RevId: 72b7bf041e873f40ef95db97e897e628a714f756
Modules are sorted in the modules.xml file, but entities may be added in arbitrary order due to concurrent loading. So they should be sorted during conversion to JPS model for consistency with the old implementation and have stable behavior in the build process.
GitOrigin-RevId: 1e12f2930f702b80b089985d8e91cee03da10292
This is needed to test loading external configuration in the new implementation of JPS model (IJPL-409) and to avoid conversions between Path and String.
JpsCompilerConfigurationTest changed to load the project configuration using JpsSerializationManager API and migrated to JUnit5.
GitOrigin-RevId: a9d85b2b8797cdecbc43c07339ad89511823d758
This is needed to refactor simplify JpsProjectLoader to allow reusing its code in the new implementation of the JPS model (IJPL-409).
GitOrigin-RevId: b88fb246454601489e7133df4b078e5e52f6da58
JpsProjectExtensionWithExternalDataSerializer is introduced to support project components which may have data in the external storage. Code related to loading the compiler configuration is moved from JpsProjectLoader to JpsJavaCompilerConfigurationSerializer. This is needed to refactor JpsProjectLoader to allow reusing its code in the new implementation of the JPS model (IJPL-409).
GitOrigin-RevId: c0e64c02c49e4a451da9b9743c240227bd6465a4
Users should not access all changes inside the workspace model and only process the changes that are relevant to their subsystem.
Internal discussion: https://jetbrains.slack.com/archives/G0142J1B20N/p1719324452271479
GitOrigin-RevId: 46bfaa0f41b4d92c7ec525d7505b4ba13c89532c
`iml` files of imported modules are not automatically removed due to different circumstances.
Because of this issue, the external build system did this manually for many years.
Unfortunately, this also affects the serialization of files and caused IJPL-867.
To fix the IJPL-867 issue, the following steps are taken:
- Get rid of manual `iml` removal by the external build system (`AbstractModuleDataService`).
- Update jps serializer to mark the imported iml for deletion.
- The `.iml` should not be deleted by the component store, but it's not due to IJPL-926. Ideally, we fix IJPL-926, but for now do the workaround: remove the ` iml ` file on the level of JPS serialization.
These steps fix the IJPL-867 issue, but a further fix for IJPL-926 is still needed.
# Notes
- Test `ExternalSystemProjectSaveTest` is created as a separate class that uses JUnit 4, however, this test can be placed in `ExternalSystemProjectTest`. The problem is that `ExternalSystemProjectTest` uses JUnit 3 and it freezez on `project.stateStore.save()` because of an unclear reason.
- `JpsProjectSerializersImpl.saveEntities` has a complicated logic when the `iml` file should be removed. As there is no goal to refactor/refresh this logic, I tried to minimize the number of changes around this place.
- `JpsProjectSerializersImpl.shouldDeleteImportedFile` has a corner case for broken configuration of the iml. This case is covered in `ExternalSystemStorageTest.multiple modules with the same name` test.
- `ModuleImlFileEntitiesSerializer.manuallyRemoveImlFile` has a check for the correct casing. This test case is covered in `ExternalSystemStorageTest.multiple modules with the same name but different case`.
- After the `iml` deletion, the VFS should technically be refreshed, but we don't do it because the module with JPS serialization does not have a dependency to the module with VFS. Because of that, the `iml` does not disappear immediately from the project tree if it's there. I consider that this problem is minor.
GitOrigin-RevId: e6228e06017f6aef26fb78321a27a3ad05e1c22c
Key `ide.workspace.model.separate.component.for.roots` was removed, but one field still remains in the code
GitOrigin-RevId: 8848a6f478bf02930aea427ea716769e1d1f1b02
Implementations for the following elements are provided for now:
* modules: content, source and excluded roots, custom properties of modules and source roots, dependencies;
* libraries: roots and custom properties;
* SDKs: roots and custom properties;
* java: custom properties of modules and dependencies.
GitOrigin-RevId: 1829d8defa1b36148abfbd063264defdd6c16014
