Android-runtime: Build fails with type conflict

Created on 25 Jan 2016  路  4Comments  路  Source: NativeScript/android-runtime

error:

:buildMetadata
Exception in thread "main" java.lang.IllegalArgumentException: Class android.support.v7.widget.AppCompatCheckedTextView conflict: C:\Git\nativescript-cli-tests\TNS_App\platforms\android\build\intermediates\exploded-aar\com.android.support\appcompat-v
7\23.1.1\jars\classes.jar and C:\Git\nativescript-cli-tests\TNS_App\platforms\android\build\intermediates\exploded-aar\com.android.support\appcompat-v7\22.2.1\jars\classes.jar
       at com.telerik.metadata.ClassRepo.cacheJarFile(ClassRepo.java:21)
       at com.telerik.metadata.Builder.build(Builder.java:38)
       at com.telerik.metadata.Generator.main(Generator.java:44)
:buildMetadata FAILED

problem:
Two .jar files:

  • appcompat-v723.1.1\jars\classes.jar
  • appcompat-v722.2.1\jars\classes.jar
    declare the same type android.support.v7.widget.AppCompatCheckedTextView

explanation:
With new metadata generator we fail the gradle build instead of Skip-ing errors.

done high bug

Most helpful comment

As a temporary solution, I've removed the android platform and added again later.
It's quite faster than I was expecting and worked beautifully.

tns platform remove android
tns platform add android

After that, you are good to go 馃槃

All 4 comments

This scenario happens when there are two libraries different only in their version:

  1. They are both exploded in the build/intermediates/exploded-aar/ folder.
  2. On a later stage in the build process this folder is passed and traversed recursively for all .jar files and these .jar files are passed to the metadata generator.
  3. Because two of the .jar files contain the same types, the metadata generator blows up.

Solutions:

  • Compare current gradle project compile dependencies and pass to the metadata generator only the valid ones.
    (there is no easy way of doing this, because gradle compile dependencies are absolute path files with different structure convention, not to mention .aar files that come from plugins not downloaded from jcenter or maven)
  • Delete the exploded-aar folder
    (so far this option works best although it slows the build down, when an update is necessary)

ping @rosen-vladimirov We agreed on the second approach.

This problem is very simple to reproduce. When there is an update of the template gradle file and you try to build again without using the gradle clean command, there will be some leftover exploded-aar files that will come into conflict with each other.
This problem has an easy solution:
It will be the developer's job to keep in mind that he needs to do a gradle clean in the platforms/android folder (later on it will be available through CLI), after he changed the native project's dependency configuration in some way.
example:

  • original dependency
compile "com.android.support:appcompat-v7:19.0.0"
  • newly changed dependency becomes:
compile "com.android.support:appcompat-v7:23.0.0"
  • now you made a change to the dependency configuration and you need to clean the project, so when cli is available (not yet) you will be able to do something like tns clean android, but for now you need to go to the platforms/android folder open a cmd there and execute gradlew clean

EDIT: iOS doesn't need clean command, which is a problem featurewise.

As a temporary solution, I've removed the android platform and added again later.
It's quite faster than I was expecting and worked beautifully.

tns platform remove android
tns platform add android

After that, you are good to go 馃槃

Was this page helpful?
0 / 5 - 0 ratings