Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix cache kind management with nested subprojects #3519

Merged

Conversation

AlexeyTsvetkov
Copy link
Collaborator

Previously, cache kind property management
worked incorrectly when Compose Gradle plugin
was applied to both parent and child subprojects,
e.g. :compose-subproject-1:compose-subproject-2.
With this example the plugin would successfully
set the property for compose-subproject-1,
but then for compose-subproject-2 the following snippet would fail:

if (project.hasProperty(targetCacheKindPropertyName)) {
  project.setProperty(targetCacheKindPropertyName, NONE_VALUE)
}

because project.hasProperty would have return true (because it checks parent subproject properties too), but project.setProperty would fail, because
parent project's properties are read only.

Warnings were also handled incorrectly in this case, because during the configuration of compose-subproject-1 we might set kotlin.native.cacheKind.ios*=none,
which would then cause a warning during the configuration of compose-subproject-2. To avoid incorrect warnings, we now
record the snapshot of relevant properties
during Compose Multiplatform build service initialization

Resolves #3515

Previously, cache kind property management
worked incorrectly when Compose Gradle plugin
was applied to both parent and child subprojects,
e.g. :compose-subproject-1:compose-subproject-2.
With this example the plugin would successfully
set the property for compose-subproject-1,
but then for compose-subproject-2 the following snippet
would fail:
```
if (project.hasProperty(targetCacheKindPropertyName)) {
  project.setProperty(targetCacheKindPropertyName, NONE_VALUE)
}
```
because project.hasProperty would have return true
(because it checks parent subproject properties too),
but project.setProperty would fail, because
parent project's properties are read only.

Warnings were also handled incorrectly in this case,
because during the configuration of compose-subproject-1 we might set
`kotlin.native.cacheKind.ios*=none`,
which would then cause a warning during the configuration of compose-subproject-2.
To avoid incorrect warnings, we now
record the snapshot of relevant properties
during Compose Multiplatform build service initialization

Resolves #3515
@AlexeyTsvetkov AlexeyTsvetkov merged commit 87d1972 into support/1.5.0 Aug 17, 2023
3 checks passed
@AlexeyTsvetkov AlexeyTsvetkov deleted the support/1.5.0-fix-nested-subprojects-cache-kind branch August 17, 2023 16:45
igordmn pushed a commit that referenced this pull request Aug 17, 2023
* Fix cache kind management with nested subprojects

Previously, cache kind property management
worked incorrectly when Compose Gradle plugin
was applied to both parent and child subprojects,
e.g. :compose-subproject-1:compose-subproject-2.
With this example the plugin would successfully
set the property for compose-subproject-1,
but then for compose-subproject-2 the following snippet
would fail:
```
if (project.hasProperty(targetCacheKindPropertyName)) {
  project.setProperty(targetCacheKindPropertyName, NONE_VALUE)
}
```
because project.hasProperty would have return true
(because it checks parent subproject properties too),
but project.setProperty would fail, because
parent project's properties are read only.

Warnings were also handled incorrectly in this case,
because during the configuration of compose-subproject-1 we might set
`kotlin.native.cacheKind.ios*=none`,
which would then cause a warning during the configuration of compose-subproject-2.
To avoid incorrect warnings, we now
record the snapshot of relevant properties
during Compose Multiplatform build service initialization

Resolves #3515

* Fix issues from code review
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants