I'm having some trouble integrating Compose `1.0.0...
# compose
d
I'm having some trouble integrating Compose
1.0.0-beta08
into an existing application with Kotlin
1.5.10
and AGP
7.1.0-alpha02
. I'm getting the following error and I'm not sure how to further debug it. More details in 🧵
Copy code
java.lang.NoSuchMethodError: No static method setContent$default(...)
I've tried the solutions from stack overflow posts and similar issues in this channel but no luck yet. Seems like the usual suspect is missing
kotlinCompilerExtensionVersion
but I have that. I have all of the following:
Copy code
buildFeatures {
        compose true
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    kotlinOptions {
        jvmTarget = "1.8"
        freeCompilerArgs += "-Xallow-jvm-ir-dependencies"
	// Gives "w: Flag is not supported by this version of the compiler: -Xallow-jvm-ir-dependencies"
    }

    composeOptions {
        kotlinCompilerVersion '1.5.10'
        kotlinCompilerExtensionVersion '1.0.0-beta08'
    }
I also tried setting
kotlinOptions.useIR = true
but it says it's deprecated and has no effect in 1.5.10 I'm using the latest
activity-compose
library,
1.3.0-beta01
a
can you paste more of the stack trace?
d
Yep sorry:
Copy code
java.lang.NoSuchMethodError: No static method setContent$default(Landroidx/activity/ComponentActivity;Landroidx/compose/runtime/CompositionContext;Lkotlin/jvm/functions/Function0;ILjava/lang/Object;)V in class Landroidx/activity/compose/ComponentActivityKt; or its super classes (declaration of 'androidx.activity.compose.ComponentActivityKt' appears in /data/app/~~0N8EjwXJ4bUjj7UeohjOLQ==/com.chalk.planboard.dev-SNl_FACaLy7V4N-4Febf3g==/base.apk)
        at com.chalk.planboard.ui.attachments.AttachmentsActivity.onCreate(AttachmentsActivity.kt:77)
c
Make sure you're using latest fragment deps and activity-compose dep too possibly. I don't actually know if that's the issue, but those being out of date has bitten me in the past. I did wish that compose had better error messaging when integrating it. Maybe some updated docs on how to integrate into an existing app would be good because I know some of the current code snippets of the docs are out of date.
a
this might even be a clean and rebuild scenario if this was right after an update somewhere
d
Updated all androidx dependencies to latest before trying to integrate compose, and made sure activity-compose is up to date as well at 1.3.0-beta01. Tried a few clean/rebuilds already, made sure to disable gradle build caching, did an AS invalidate/restart but still no luck 😕 I've created new compose projects with no issues, only differences I can think of are: - this project has a mix of groovy/kts gradle files - this app consumes a multiplatform module but doesn't use the multiplatform plugin directly - this app still uses kotlin synthetics/parcelize and jetifier Could any of those conflict with it?
a
I've heard some folks have issues with synthetics in particular
c
Do you happen to be using buildSrc by chance?
d
Ah okay I could see about getting rid of synthetics then
And yep using buildSrc - does that cause any issues?
c
I've had issues that seem similar to this. Let me find the issue tracker.
d
That was it! Thanks @Colton Idle 🙌
c
Wooo. That bug took me literally forever to track down. Jim helped debug that with me for like a week it seemed.
d
Yeah I can imagine, I don't think I ever would have figured that out... would not expect that to be an issue at all
c
@jim sorry to ping, but since you helped me originally debug this issue wayyy back. Do you think this is one of those things that should be potentially called out in the documentation. something like ⚠️ Warning If you use Gradle buildSrc you may have to add an additional dependency
j
Ugg, that issuetracker thread makes me want to barf. Well, I suppose Gradle is the one that makes me want to barf, why is the underlying issue always gradle doing crazy shit?
👌 2
I’m not entirely sure adding warnings all over the docs is the right solution here. If we started doing this, we would have a whole cloud of warnings, I think the probability that the right person is going to happen to see the right warning would be close to zero. I’ll ping our release notes managers to see if they have thoughts. With regards to a proper fix, I think we’ve bounced the idea of deprecating-and-suppressing all composables. I think this was a controversial approach (maybe just because of the name "deprecated"), but it was the one recommended by Jetbrains. Anyway maybe we can find a better path forward that surfaces a reasonable error at the right time. cc @Adam Powell
c
Yeah. I like the idea of simply "improving" the error message in this case.
I'm also going to go into the gradle slack channel and just ask there if they have any thoughts. 😄 Edit: idk if anyone is on gradle slack but here's a link if you want to follow that. https://gradle-community.slack.com/archives/CA7UM03V3/p1623348807217200 I just know a ton of people use buildSrc and want to improve the life for those people.
👍 1