Jetpack Compose 现有多模块应用程序中的依赖项

Question

I'm facing issues while integrating jetpack compose in a multi-module project.

One module library has all the dependencies for jetpack compose, and I am able to compile and Run the jetpack compose code written inside that module.

 android {
    ...
   kotlinOptions {
      jvmTarget = '1.8'
      useIR = true
   }

   buildFeatures {
      compose true
   }

   composeOptions {
      kotlinCompilerExtensionVersion compose_version
      kotlinCompilerVersion '1.4.21'
   }
 }


dependencies {
   ...
   implementation "androidx.compose.ui:ui:$compose_version"
   implementation "androidx.compose.material:material:$compose_version"
   implementation "androidx.compose.ui:ui-tooling:$compose_version"
   ...
}

Where compose_version = '1.0.0-alpha09'

Issue comes when I add that library module into app module and integrate the jetpack compose there. It requires to add all the dependencies inside app module's build.gradle.kts file also.

After adding same code of lines, gradle task (:app:compileDebugKotlin) keeps running in infinite loop without any error message.

What i am doing wrong here? any help would be appreciable. Thanks!

Update-1 Running gradlew compileDebugKotlin --debug, It stuck with below stack-trace

2020-12-30T12:26:42.079+0530 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on 
daemon addresses registry.
2020-12-30T12:26:42.079+0530 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire 
shared lock on daemon addresses registry.
2020-12-30T12:26:42.080+0530 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on 
daemon addresses registry.
2020-12-30T12:26:42.080+0530 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on 
daemon addresses registry.

Answer 1

I've had a very similar problem, exactly the same stacktrace. In my case it was caused by kotlin synthetic (android-kotlin-extensions) plugin. Removing the plugin (as suggested in Adding buildFeatures { compose true } causes build to take indefinitely. How to investigate issue? ) resolved the issue.