Status Update
Comments
tn...@google.com <tn...@google.com> #2
Room version > 2.7.0-alpha08
agp = "8.2.2"
kotlin = "2.0.20"
ksp-plugin = "2.0.20-1.0.24"
also Reverting to Room version 2.7.0-alpha07 solves the issue.
al...@google.com <al...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Configure the schema asset android copy task within its register block and not within AGP's wiredWith lambda.
Expand for full commit details
Configure the schema asset android copy task within its register block and not within AGP's wiredWith lambda.
Otherwise the tasks inputs are locked by the time the wiredWith lambda passed to addGeneratedSourceDirector() is invoked and will lead to "property 'inputDirectory' is final and cannot be changed any further".
Bug: 376071291
Test: Manual with sample repro app
Change-Id: I2c9da4855cd31d7df3276424546aba4c53edf7ea
Files:
- M
room/room-gradle-plugin/src/main/java/androidx/room/gradle/integration/AndroidPluginIntegration.kt
Hash: 1dbb4c1876e1e8a8e930bec4625741ac6dc05a0b
Date: Thu Dec 05 14:21:51 2024
tn...@google.com <tn...@google.com> #5
tasks.matching { it.name.startsWith("copyRoomSchemasToAndroidTestAssetsDebugAndroidTest") }.configureEach {
enabled = false
}
But I believe this is not the right thing to do, since I'm hiding the error. Is there another way to solve it or will the library be updated to fix it?
al...@google.com <al...@google.com> #6
Unfortunately the fix did not make it to the alpha12 release, but it will indeed be in the next release.
al...@google.com <al...@google.com>
bu...@google.com <bu...@google.com> #7
When will this be released? It's more than a month now?
an...@google.com <an...@google.com> #8
Sorry for the delay - Next androidx release is January 29
ow...@google.com <ow...@google.com> #9
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.room:room-gradle-plugin:2.7.0-alpha13
al...@google.com <al...@google.com> #10
Pulling off BugJuggler so we can discuss this in weekly meeting.
al...@google.com <al...@google.com>
al...@google.com <al...@google.com> #11
Looking into whether this is really blocked on
al...@google.com <al...@google.com> #12
Detected these failing tasks: [':annotation:annotation:compileKotlinJvm']
> Task :annotation:annotation:compileKotlinJvm
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/Px.kt:28:1 This annotation is not applicable to target 'annotation class'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresApi.kt:52:5 This annotation is not applicable to target 'value parameter'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresApi.kt:54:5 This annotation is not applicable to target 'value parameter'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresExtension.kt:64:5 This annotation is not applicable to target 'value parameter'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresExtension.kt:66:5 This annotation is not applicable to target 'value parameter'
And we're immediately hit by this ourselves.
public annotation class RequiresApi(
/**
* The API level to require. Alias for [.api] which allows you to leave out the `api=` part.
*/
@IntRange(from = 1) val value: Int = 1,
/** The API level to require */
@IntRange(from = 1) val api: Int = 1
)
The annotation needs to be moved next to Int
. This would be highly disruptive for clients.
Maybe we don't?
al...@google.com <al...@google.com> #13
Or, at the very least, maybe we add TYPE_USE
but don't remove the targets?
tn...@google.com <tn...@google.com> #14
Please don't add type use to these annotations without also updating the lint analysis to support/check on types.
al...@google.com <al...@google.com> #15
without also updating the lint analysis to support/check on types.
Lint team would need to do that, but I'm happy to provide motivation. We have a parallel bug for Metalava that my team would be handling.
al...@google.com <al...@google.com> #16
Or, at the very least, maybe we add
TYPE_USE
but don't remove the targets?
We could consider adding TYPE_USE
, implementing a lint check with auto-fix to migrate, and effectively "deprecating" the other targets. It would still be extremely disruptive, though. And we'd be on the hook for migrating google3, which would be somewhere between difficult and impossible.
tn...@google.com <tn...@google.com> #17
Lint team would need to do that, but I'm happy to provide motivation. We have a parallel bug for Metalava that my team would be handling.
Right -- just making it clear that this isn't currently in the plans from the lint team, so let's not update the public annotations with type use and then leaving tools support as TODO, since the primary purpose of these annotations is enforcement.
al...@google.com <al...@google.com> #18
Putting this on the backburner again. There are still some big questions around whether this is a good idea given the trade-offs around (1) disrupting clients and (2) ownership in g3.
bu...@google.com <bu...@google.com> #19
Bugjuggler:
al...@google.com <al...@google.com> #20
We have an owner and time scheduled for the blocking issue, so this is likely to make progress in Q3.
Right -- just making it clear that this isn't currently in the plans from the lint team, so let's not update the public annotations with type use and then leaving tools support as TODO, since the primary purpose of these annotations is enforcement.
Unclear what we'll do about lint, though. Tor, I'm finding a couple of bugs filed against Lint public component that touch on type annotations but nothing that's obviously "implement support for TYPE
." Is there an existing bug that I can use as blocking, or do you want a new one?
bu...@google.com <bu...@google.com>
ga...@linecorp.com <ga...@linecorp.com> #21
Related with
b/209843426 https://youtrack.jetbrains.com/issue/KT-48900 https://youtrack.jetbrains.com/issue/KT-67981
Since Kotlin 1.6, kotlin compiler warns when use androidx.annotation in Container types. Also, Since kotlin 2.0, kotlin compiler warning cannot be suppressed and it looks that Kotlin compiler team will not provide workaround to suppress.
Description
When we have
@Nullable
and@UiContext
conceptually refer to theContext
, the return type, while@override
and@MainThread
refer to the function.As far as I know, this is because pre-Java-8,
AnnotationTarget.TYPE
did not exist. I believe the most correct way to have that code in the post-Java-8-world isProposal: migrate all (androidx) annotations that conceptually refer to types away from
AnnotationTarget.Method
(/Getter
?) toAnnotationTarget.TYPE
.Because:
@TypeBound
annotation added to Kotlin, which would allowfun foo(c: @UiContext Context)
to throw a compile-time error when passed a non-@UiContext
context
, ifannotation class UiContext
was@TypeBound
. This could be useful for@*Context
and@*Res
, among others. Not everything is Kotlin yet, but we should be forward-looking.The annotations I believe this applies to:
KNOWN_TYPEBOUND_ANNOTATION_NAMES = "Dimension", "Px", "Size"
KNOWN_TYPEBOUND_ANNOTATION_SUFFIXES = listOf("Res", "Range", "Long", "Int", "Float", "Context")
Including nullability annotations, this comes out to 35 androidx annotations at the current time.
Plan:
AnnotationTarget.TYPE
.@Deprecate
ing certainAnnotationTargets
and deprecateAnnotationTarget.METHOD
for the applicable androidx annotations.androidx.annotation
, remove the deprecatedAnnotationTarget.METHOD
.@TypeBound
is accepted, consider how it could be made use of.Caveat: this is assuming the minimum java version we support is Java8. I believe this is the case, or will be by the time we reach step 5 (and that lower versions are deprecated by step 3). Do we have an official policy on this topic?