Part 1, initial commit of JS part.
(cherry picked from commit 8e28858f8e6b206b044c4b7cb46a6d4932a7e29d)
(cherry picked from commit f75ec86191d844fce62acb7d0f3835349d48378d)
IJ-CR-155171
GitOrigin-RevId: 16ddacb8aa77275dd894c488d36931670e45881c
... because `JupyterCefPathHandler` is not a true "path handler" and doesn't fit into `BuiltInWebServer` security model; decoupling makes `WebServerPathHandler` easier to refactor. Besides, it delegates to an instance of `JupyterCefHttpHandler` anyway and needs an anonymous object to access `HttpRequestHandler#sendData` - so merging simplifies both the code and the logic.
(cherry picked from commit bd2122b0f2bbd2ae74da4dc2bdada6de1ccc3e1b)
(cherry picked from commit 7f157366ebb72b7083149e2a8d3a74bb17786f40)
IJ-CR-155171
GitOrigin-RevId: 8798ac40ef8abf9ed2e2994a28bd32b00ffed267
The icon was available only for version catalogs with custom location.
Code review: IJ-CR-153925
(cherry picked from commit b00d2ccd1901705489097ad193dcd97cb0fb9062)
GitOrigin-RevId: 65fbd12dbe95f05763bb8d64c65ab7c1cd67db3c
- fixes completion for "libs" `GradleVersionCatalogsCompletionTest#testCompletionForVersionCatalogProperty`
- also enables completion for all other version catalog names of a build
I realized that `GradleExtensionsContributor#processPropertiesFromCatalog` is called not only while resolving but also while completion: when only a part of catalog name was written. In this case, `name` argument is `null` and accessors should be created for all version catalogs of the corresponding build. To achieve that, I added `GradleVersionCatalogHandler#getAccessorsForAllCatalogs`.
I decided to add a separate method for getting all accessors because if I use the existing `getAccessorClass`, it would recreate `ProjectBuildModel` for each version catalog.
Code review: IJ-CR-153925
(cherry picked from commit 1250f5b3bb22b6ed1968683b0b6144418d0ad70f)
GitOrigin-RevId: 3f270387510983fbd51ba630c54a04db7d5a5025
In runtime, navigation did not work for this example:
`my<caret>Libs`.junit.jupiter
Where myLibs is a name of a version catalog defined in settings.gradle. However, navigation would work if the caret is located on `junit`.
The Interesting point is that `GradleVersionCatalogsResolveTest` has the test `testNavigationToTomlFile2` that covers this case. It was passing well because:
- in runtime, references to version catalogs are resolving using the data from the Android module. The corresponding Psi elements - StaticVersionCatalogProperty are created in GradleExtensionsContributor.kt
- in tests, references were resolved using the older approach which still works if android module does not provide version catalogs. It didn't because GroovyDslParser from the android module was not available in tests. Hence, reference was resolved using the GradleExtensionProperty PSI element created in GradleProjectExtensionContributor.kt
Code review: IJ-CR-153925
(cherry picked from commit de4bcd81a61a3bc45119857357f43a8a21a75392)
GitOrigin-RevId: a143eb4a149cea8cc549986023793912bd5c869d
The changes in this commit allow resolving references to version catalogs in included builds of a composite build if android module provides these version catalogs.
I found two existing approaches to resolve a reverence with a name of a version catalog (e.g. 'myLibs') to a TOML file:
1) Using the data from VersionCatalogsModel that is prepared at sync in `CommonGradleProjectResolverExtension#populateProjectExtraModels`.
Resolve happens in `GradleProjectExtensionContributor`. It works well for simple projects, not composite ones.
This allows navigation to a version catalog with custom location that could be specified in settings.gradle
2) Using the data from `ProjectBuildModel` that is prepared in android module. Resolve happens in `GradleExtensionsContributor`.
It works only if the code in android module correctly discovers version catalogs and provides them.
In comparison to the first approach, the data is compared not while syncing but when it is requested
Code review: IJ-CR-153925
(cherry picked from commit d2859302e5aba22413d3b1da874bff1cd15c46b2)
GitOrigin-RevId: f2f65eff37cbfed5da79cfa570fa61caafc667a2
- use language level to predict the order of comments
(cherry picked from commit e7986fcb2302dde7ad80fae9346f6a27edb576ae)
GitOrigin-RevId: f1cee2d3123a9a9845f999ac03984427799c84db
"cannot reference super before superclass constructor is called"
(cherry picked from commit a2eeb5211fed697bc99ec9620bca4493c5a7adae)
GitOrigin-RevId: 6c404d216a804825e70d5c37866e3055dc8c5443
- new options are added
- changes for optimize imports
(cherry picked from commit 82b0223f9e7e2972d13ab182ea651cdccd28a5d3)
GitOrigin-RevId: 99f0276e1d9464f75f5bbce91ad09727582d208b
- support transitive for dependencies on 'java.base' module
(cherry picked from commit a364934e96592ae3a8244ae68b2fb5372e7f5a30)
GitOrigin-RevId: 6bffa2d03645e77537d70cd4d9d081dec80680af
- support shadowing module imports by package-on-demand
(cherry picked from commit 643fc10bcbfee2f1d41ec02e624b30bc3a48e4bb)
GitOrigin-RevId: d1e49b2d48f0b69f8e15393cb823e5529f9b4452
enabled by default for consistency with other tools
(cherry picked from commit df5a4b65c5f31b195bd091a91d16ea0bc7bcc36c)
GitOrigin-RevId: 3b669ce15e9ad037bcff9c1e2638e2b823424ef7
