When building a project, the issue that came up was like below
* What went wrong:
Execution failed for task ':app:transformDexArchiveWithExternalLibsDexMergerForDebug'.
Program type already present: android.arch.lifecycle.ViewModel
Based on the details given below in the reference, the issue can occur in below cases
This error typically occurs due to one of the following circumstances:
1. A binary dependency includes a library that your app also includes as a direct dependency.
For example, your app declares a direct dependency on Library A and Library B, but Library A already includes Library B in its binary.
To resolve this issue, remove Library B as a direct dependency.
2. Your app has a local binary dependency and a remote binary dependency on the same library.
To resolve this issue, remove one of the binary dependencies.
Fix conflicts between classpaths
When Gradle resolves the compile classpath, it first resolves the runtime classpath and uses the result to determine what versions of dependencies should be added to the compile classpath. In other words, the runtime classpath determines the required version numbers for identical dependencies on downstream classpaths.
Your app's runtime classpath also determines the version numbers that Gradle requires for matching dependencies in the runtime classpath for the app's test APK. The hierarchy of classpaths is described in figure 1.
Conflict with dependency 'com.example.library:some-lib:2.0' in project 'my-library'.
Resolved versions for runtime classpath (1.0) and compile classpath (2.0) differ.
You might see this conflict when, for example, your app includes a version of a dependency using the implementation dependency configuration and a library module includes a different version of the dependency using the runtimeOnly configuration. To resolve this issue, do one of the following:
Include the desired version of the dependency as an api dependency to your library module. That is, only your library module declares the dependency, but the app module will also have access to its API, transitively.
Alternatively, you can declare the dependency in both modules, but you should make sure that each module uses the same version of the dependency. Consider configuring project-wide properties to ensure versions of each dependency remain consistent throughout your project.
references:
https://developer.android.com/studio/build/dependencies#duplicate_classes
* What went wrong:
Execution failed for task ':app:transformDexArchiveWithExternalLibsDexMergerForDebug'.
Program type already present: android.arch.lifecycle.ViewModel
Based on the details given below in the reference, the issue can occur in below cases
This error typically occurs due to one of the following circumstances:
1. A binary dependency includes a library that your app also includes as a direct dependency.
For example, your app declares a direct dependency on Library A and Library B, but Library A already includes Library B in its binary.
To resolve this issue, remove Library B as a direct dependency.
2. Your app has a local binary dependency and a remote binary dependency on the same library.
To resolve this issue, remove one of the binary dependencies.
Fix conflicts between classpaths
When Gradle resolves the compile classpath, it first resolves the runtime classpath and uses the result to determine what versions of dependencies should be added to the compile classpath. In other words, the runtime classpath determines the required version numbers for identical dependencies on downstream classpaths.
Your app's runtime classpath also determines the version numbers that Gradle requires for matching dependencies in the runtime classpath for the app's test APK. The hierarchy of classpaths is described in figure 1.
Conflict with dependency 'com.example.library:some-lib:2.0' in project 'my-library'.
Resolved versions for runtime classpath (1.0) and compile classpath (2.0) differ.
You might see this conflict when, for example, your app includes a version of a dependency using the implementation dependency configuration and a library module includes a different version of the dependency using the runtimeOnly configuration. To resolve this issue, do one of the following:
Include the desired version of the dependency as an api dependency to your library module. That is, only your library module declares the dependency, but the app module will also have access to its API, transitively.
Alternatively, you can declare the dependency in both modules, but you should make sure that each module uses the same version of the dependency. Consider configuring project-wide properties to ensure versions of each dependency remain consistent throughout your project.
references:
https://developer.android.com/studio/build/dependencies#duplicate_classes
No comments:
Post a Comment