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
There was a warning:
"Only method calls to 'id' and 'alias' are available in 'plugins' block"
in .groovy files with a content like:
```
plugins {
apply 'df' named 'ffd'
}
```
(cherry picked from commit 4d22b23e04432d3b882b330eacee7beb2740c95d)
IJ-MR-149922
GitOrigin-RevId: 54ff53d34d60c5fc3b20331bd5a3fd29f518c27c
Do not force test to be run in a single thread unless this task is going to be debugged.
(cherry picked from commit e90d2c89d07119d4fc5c394d709ebdcace989805)
IJ-CR-146790
GitOrigin-RevId: 03e1b1b29a33e0e28086ba04053bd30d350b042a
All run configurations that can be run in the Gradle delegated mode should implement GradleExecutionEnvironmentProvider. It is already implemented for Micronaut, Ktor and Spring Boot.
GitOrigin-RevId: d4262bd31745f5f908e158d22d7c4e7b0618942f
Each included build (linked project) could have its own version catalogs, different to the catalogs of a root composite build. This change makes possible accessing version catalogs of an included build.
Also, it enables navigation from a build script (either Groovy or Kts) in an included build to a corresponding version catalog.
For example, from `/app/build.gradle` to `/app/gradle/libs.versions.toml`, where `app` is a build included in the settings file of the composite build using `includeBuild("app")`
GitOrigin-RevId: ed5d68cb91e7fe74c0af1755e3cbfa7b3b2d1abf
Gradle will warn if a project is added to the build where the associated projectDir does not exist or is not writable. Starting with version 9.0, Gradle will not run builds if a project directory is missing or read-only.
GitOrigin-RevId: cc34d50f0e02a7a30e041196fbc8e108a315450f
`BrowseFolderRunnable` and `*WithBrowseButton` family: getting rid of separate "title" and "description" parameters in favor of the chooser descriptor object, to avoid cloning the latter down the road.
GitOrigin-RevId: 33ec5968a1db953c60848974135055c288accf85
The previous test (ExternalAnnotationsDataServiceTest) sometimes disposes of the whole project. This should not happen.
GitOrigin-RevId: 35125e51ffdfd59c147878b9dc512c184303fac2
