Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EpoxyDataBinding models not being generated, causing compilation to fail #1014

Closed
eagskunst opened this issue Jul 7, 2020 · 4 comments
Closed

Comments

@eagskunst
Copy link

In 4.0.0, with the EpoxyDataBindingPattern (based on layoutPrefix), sometimes when running the app (re-compiling with cache), the build fails because the extensions and the 'Model_'s can not be referenced. If I look inside the generated code package, there are not classes referencing my DataBinding models. This does not happen for ModelViews and EpoxyModelWithHolder.

Currently, I have two ways of generate the models again:

  1. Rebuilding the project from scratch (takes too long).
  2. Modifiying any layout that is a reference for ViewBinding/DataBinding (takes some time too, but less than rebuilding the project).

The second method has also worked for me for ViewBinding classes that for some reason, are deleted after compiling the app (the compilation error dissapears instantly.)

This does not happens with lower versions of the library (3.11 and below).

AS version: 4.0

gradle.properties file:

org.gradle.parallel=true
org.gradle.caching=true
org.gradle.jvmargs=-Xmx2048M -Dkotlin.daemon.jvm.options\="-Xmx2048M"
kotlin.code.style=official
android.enableJetifier=true
android.useAndroidX=true
kotlin.incremental=true
kapt.incremental.apt=true 
kapt.use.worker.api=true
android.databinding.incremental=true
android.lifecycleProcessor.incremental=true
room.incremental = true

package-info.java:

 @EpoxyDataBindingPattern(rClass = R.class, layoutPrefix = "view_holder")
 package com.kinesis.kinesisapp;

 import com.airbnb.epoxy.EpoxyDataBindingPattern;

Part of my app's module's build.gradle file:

  android {
    buildFeatures {
       dataBinding = true
        viewBinding = true
    }
   compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    kotlinOptions {
         jvmTarget = "1.8"
    }

}
kapt {
    correctErrorTypes = true
    showProcessorTimings = true
}

project.android.buildTypes.all { buildType ->
    buildType.javaCompileOptions.annotationProcessorOptions.arguments =
            [
                    "room.schemaLocation":"$projectDir/schemas".toString(),
                    "room.incremental":"true",
                    requireHashCodeInEpoxyModels: "true",
                    requireAbstractEpoxyModels  : "true",
                    enableParallelEpoxyProcessing     : "true",
            ]
}
@eagskunst
Copy link
Author

I manage to reproduce this in the Kotlin sample on my fork. This is the branch. Steps to reproduce:

  1. Run the kotlinsample, everything should run succesfully since it's a clean run.
  2. On the MainActivity from the kotlinsample, add a variable to the DataObject class at the end of the file (I reproduce it with an Int) and pass it to the constructor in 50 line.
  3. The compilation fails on compileDebugKotlin task, compliying for unresolved references for the models that should be generated from XML files.

@eagskunst
Copy link
Author

I added the 'kapt.verbose' to my fork's gradle.properties and found that in the kotlinsample, when there's no changes on files referencing by the DataBinding processor, there are 0 rounds. Maybe this is due to incremental builds? Weird thing is that the ModelViewProcessor always do 3 rounds (I have not touched any of the files related to that processor).

@eagskunst
Copy link
Author

eagskunst commented Jul 9, 2020

I found a solution but with two downsides. Changing the IncrementalAnnotationProcessorType of DataBindingProcessor to ISOLATING fixes the error and does not delete (or always generate?) the DataBindingModel_ and DataBindingModelBuilder files.

Downsides:

  1. The kapt logs shows the following:
    [WARN] Issue detected with com.airbnb.epoxy.processor.DataBindingProcessor. Expected 1 originating source file when generating C:\Android_programming\epoxy\kotlinsample\build\generated\source\kapt\debug\com\airbnb\epoxy\kotlinsample\DataBindingItemBindingModelBuilder.java, but detected 0: [].
    Which, from my little understading, says that this type of processor expects a File to be annotated with the supported annotations.

  2. This make the processor do rounds even if there are no changes with files related to the target (layout, controllers and classes referenced by the layout inside the data tag).

@elihart
Copy link
Contributor

elihart commented Jul 10, 2020

Thank you for the detailed report and investigation, I appreciate it!

I believe I know the issue and have a fix (we ran into the same problem on another project).

It is an incremental annotation processing bug. The root cause is a bit tricky - essentially the only annotation that the processor uses is the package annotation in package-info.java. There is a quirk (or bug?) in kapt where package-info.java is not treated as an input source, so it thinks there are no sources to reprocess and the processor doesn't get run (and no files are generated).

The workaround is to put the annotation on anything else - a class or interface is the simplest. I need to change the source to allow the annotation to have @Target(ElementType.TYPE), then in your project you can move the annotation to an interface

@EpoxyDataBindingPattern(rClass = R.class, layoutPrefix = "view_holder")
@EpoxyDataBindingLayouts({R.layout.model_with_data_binding})
interface EpoxyDataBindingConfig {} 

Note that due to a quirk with annotation processing and how the layout name is extracted from the annotation during processing this file needs to be in java.

I have fixed it in d470efe and am currently pushing a 4.0.0-beta5 release that should be available in the next hour

@elihart elihart closed this as completed Jul 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants