Fixed
Status Update
No update yet.
Comments
xa...@google.com
yb...@google.com
- A number of absolute paths are specified as annotation processor parameters in `options.compilerArgs`:
This is necessary so that we can read the SDK to grab method versions etc. FYI this is a common request by other annotation processors.
-Aandroid.databinding.generationalFileOutDir
Data Binding annotation processor generates some outputs which are shipped inside the aar file.
-Aandroid.databinding.xmlOutDir
This folder includes a list of xml files generated by Android Gradle Plugin.
-Aandroid.databinding.exportClassListTo
This folder is used to clean stub classes generated by the compiler. We have plans to get rid of it.
This is necessary so that we can read the SDK to grab method versions etc. FYI this is a common request by other annotation processors.
-Aandroid.databinding.generationalFileOutDir
Data Binding annotation processor generates some outputs which are shipped inside the aar file.
-Aandroid.databinding.xmlOutDir
This folder includes a list of xml files generated by Android Gradle Plugin.
-Aandroid.databinding.exportClassListTo
This folder is used to clean stub classes generated by the compiler. We have plans to get rid of it.
yb...@google.com
- A source file is generated called `DataBindingInfo.java` with a random UUID that changes every time a new file is generated:
Javac is not necessarily invalidated when XML files changed. But data binding may need to so if user changes any binding expressions, we use that class to re-rigger the javac. (hence that random uuid)
Javac is not necessarily invalidated when XML files changed. But data binding may need to so if user changes any binding expressions, we use that class to re-rigger the javac. (hence that random uuid)
yb...@google.com
FYI if user does not change any code in XML or javac, that code won't be generated. If they do, we have to recompile (because they might be accessing any code in their binding expressions).
xa...@google.com
The issue with the UUID is that it's random and changes from one machine to another, so this breaks distributed caching.
This is the same with the absolute paths.
This is the same with the absolute paths.
yb...@google.com
we can try to build a consistent has instead of UUID though it will be slower unless gradle can provide us the hash it already calculated for dependencies (afaik, gradle uses hashes to figure out if deps has changed, correct me if i'm wrong).
but about the absolute path, how does any other app handle it? Technically, each machine has an SDK that might be different. Do we just assume that all SDKs are backward & forward compatible?
About other absolute paths, they can all be relative since they are in the build folder.
but about the absolute path, how does any other app handle it? Technically, each machine has an SDK that might be different. Do we just assume that all SDKs are backward & forward compatible?
About other absolute paths, they can all be relative since they are in the build folder.
lo...@gradle.com
== UUID ==
A consistent hash as an ID would be best. We could expose the cache ID I guess, but we'd need to discuss this internally first. What data should be part of that hash?
== Absolute paths ==
There's two problems here. One is that currently Gradle only tracks the absolute path, but not the contents of the inputs. It also has no idea that it should track any outputs: all Gradle sees now is plain string inputs.
We will introduce a better way to describe annotation processor parameters in a rich way in Gradle 4.5. This will allow Gradle to understand the role of the values passed as annotation processor parameters, i.e. whether they should be treated as `@InputFiles` or an `@OutputDirectory`, what path sensitivity to use etc. Until then this can be worked around the same way we hack annotation processor source output (`-s`) here:https://github.com/gradle/android-cache-fix-gradle-plugin/blob/master/src/main/groovy/org/gradle/android/AndroidCacheFixPlugin.groovy#L97-L114
A consistent hash as an ID would be best. We could expose the cache ID I guess, but we'd need to discuss this internally first. What data should be part of that hash?
== Absolute paths ==
There's two problems here. One is that currently Gradle only tracks the absolute path, but not the contents of the inputs. It also has no idea that it should track any outputs: all Gradle sees now is plain string inputs.
We will introduce a better way to describe annotation processor parameters in a rich way in Gradle 4.5. This will allow Gradle to understand the role of the values passed as annotation processor parameters, i.e. whether they should be treated as `@InputFiles` or an `@OutputDirectory`, what path sensitivity to use etc. Until then this can be worked around the same way we hack annotation processor source output (`-s`) here:
yb...@google.com
== UUID ==
All inputs of the task. I'm not sure how gradle works but I thought it was already calculating a hash for all dependencies (or a list of hashes). If so, we can use that has as the UUID but need a way to get that information from the task system.
All inputs of the task. I'm not sure how gradle works but I thought it was already calculating a hash for all dependencies (or a list of hashes). If so, we can use that has as the UUID but need a way to get that information from the task system.
lo...@gradle.com
Exposing that functionality would be an option, but it would be nice to first see this work by calculating its own hash so that we are not blocked on Gradle functionality being available.
yb...@google.com
right now this task has output of merged resources + java compilation sources as input.
Does gradle have a utility class to calculate hash for a FileTree or should we implement this manually?
Does gradle have a utility class to calculate hash for a FileTree or should we implement this manually?
je...@google.com
lo...@gradle.com
There is no such Gradle feature.
Another approach we discussed is that we could implement the same normalization for `@CompileClasspath`s as we already have for `@Classpath` inputs. I.e. you could declare that this file should be excluded for both use cases, something like this:
```
normalization {
runtimeClasspath {
ignore "**/DataBindingInfo.class"
}
compileClasspath {
ignore "**/DataBindingInfo.class"
}
}
```
Another approach we discussed is that we could implement the same normalization for `@CompileClasspath`s as we already have for `@Classpath` inputs. I.e. you could declare that this file should be excluded for both use cases, something like this:
```
normalization {
runtimeClasspath {
ignore "**/DataBindingInfo.class"
}
compileClasspath {
ignore "**/DataBindingInfo.class"
}
}
```
yb...@google.com
that seems reasonable. jedo@, i guess we can add it automatically in the Android Gradle Plugin if data binding is enabled, right?
lo...@gradle.com
Please note that the `runtimeClasspath` normalization is already a feature, but the `compileClasspath` normalization is not. We could do it in Gradle 4.5 if needed I think.
mz...@gmail.com
Is there an ETA for compileClasspath to be included in gradle?
"FYI if user does not change any code in XML or javac, that code won't be generated. If they do, we have to recompile (because they might be accessing any code in their binding expressions)."
Even if I change only a java file with no databinding or UI associations, this file is still regenerated and triggers javac. Is there a way to only trigger javac if a databinding-related class changes?
"FYI if user does not change any code in XML or javac, that code won't be generated. If they do, we have to recompile (because they might be accessing any code in their binding expressions)."
Even if I change only a java file with no databinding or UI associations, this file is still regenerated and triggers javac. Is there a way to only trigger javac if a databinding-related class changes?
lo...@gradle.com
There are further breakages since in 3.2.0-alpha02. As of 3.2.0-alpha07, there are two properties breaking relocatability:
- `-Aandroid.databinding.baseFeatureInfo=...` should be passed as an annotation processor argument via `CompileOptions.compilerArgumentProviders`. Basically, a single `CommandLineArgumentProvider` implementation could declare the `@InputFile` etc. properties, and produce the `-A...` parameters via `asArguments()`. There's an example of how that should look like here:https://docs.gradle.org/4.5.1/userguide/more_about_tasks.html#sec:task_input_nested_inputs
- Somewhere `TaskInputs.dir()` is called for `AndroidJavaCompile` that adds the following directory without a property name or path sensitivity as an input directory: `/private/var/folders/66/l8mbhvns2ml4ck2r3dgtq3100000gn/T/junit3467505087742556066/junit376965362092944224/app/build/intermediates/feature_data_binding_base_feature_info/debug`
- `-Aandroid.databinding.baseFeatureInfo=...` should be passed as an annotation processor argument via `CompileOptions.compilerArgumentProviders`. Basically, a single `CommandLineArgumentProvider` implementation could declare the `@InputFile` etc. properties, and produce the `-A...` parameters via `asArguments()`. There's an example of how that should look like here:
- Somewhere `TaskInputs.dir()` is called for `AndroidJavaCompile` that adds the following directory without a property name or path sensitivity as an input directory: `/private/var/folders/66/l8mbhvns2ml4ck2r3dgtq3100000gn/T/junit3467505087742556066/junit376965362092944224/app/build/intermediates/feature_data_binding_base_feature_info/debug`
yb...@google.com
jedo@, i know there was a plan to merge the annotationProcessor args w./ the new gradle API. Do you have any update on that?
yb...@google.com
quick update,
we had a video call w/ gradle and seems like if we move data binding to use the new annotation processor args thing, this should just work w/o the UUID file.
For the SDK input, we can just drop it as the SDK is expected to be the same no matter where it is located (we still have app's min api as the input which is necessary)
we had a video call w/ gradle and seems like if we move data binding to use the new annotation processor args thing, this should just work w/o the UUID file.
For the SDK input, we can just drop it as the SDK is expected to be the same no matter where it is located (we still have app's min api as the input which is necessary)
yb...@google.com
I think this is already fixed, over to H.. to verify.
hu...@google.com
Yes, this has been fixed for Java projects that are not using the Kapt plugin.
In 3.2.0-alpha16, JavaCompile will be cacheable given the same project location (Change-Id: I1b69c0a86ef981f22634862be67d0143760dec2c).
In 3.2.0-alpha17, it will be cacheable across different project locations (Change-Id: Ibe60c7ce9142bf2fe44c9b4689b4490905dd1d1a).
In both scenarios, it is still not cacheable if Kapt is used. I'll find time to fix Kapt next, but it may or may not make it to 3.2 stable.
In 3.2.0-alpha16, JavaCompile will be cacheable given the same project location (Change-Id: I1b69c0a86ef981f22634862be67d0143760dec2c).
In 3.2.0-alpha17, it will be cacheable across different project locations (Change-Id: Ibe60c7ce9142bf2fe44c9b4689b4490905dd1d1a).
In both scenarios, it is still not cacheable if Kapt is used. I'll find time to fix Kapt next, but it may or may not make it to 3.2 stable.
ja...@google.com
Update: both JetBrains bugs have now been fixed.
hu...@google.com
We have fixed one of the two remaining caching scenarios when Kapt is used:
In 3.2.0-rc-01 (and 3.3.0-alpha-04), JavaCompile will be cacheable with Kapt given the same project location (Change-Id: Idf21b53232af260314c22ea0777d0a20a355a64e).
Fixing the last scenario (making JavaCompile cacheable with Kapt across different project locations) is pending on the following steps:
- Update our code base to Kotlin 1.2.51 or 1.2.60, whichever has the fixes for #20
- Enforce the above versions as minimum Kotlin version and remove Kapt workarounds from the AGP
This last fix might not make it to 3.2 stable (depending on how we want to prioritize it).
In 3.2.0-rc-01 (and 3.3.0-alpha-04), JavaCompile will be cacheable with Kapt given the same project location (Change-Id: Idf21b53232af260314c22ea0777d0a20a355a64e).
Fixing the last scenario (making JavaCompile cacheable with Kapt across different project locations) is pending on the following steps:
- Update our code base to Kotlin 1.2.51 or 1.2.60, whichever has the fixes for #20
- Enforce the above versions as minimum Kotlin version and remove Kapt workarounds from the AGP
This last fix might not make it to 3.2 stable (depending on how we want to prioritize it).
ja...@google.com
ta...@gmail.com
Please make it to 3.2, please make it to 3.2, pretty please.
hu...@google.com
I'm happy to inform that we have fixed the last scenario, just in time for the 3.2 release: Starting with 3.2.0-rc-02, JavaCompile will be completely cacheable, with or without Kapt. Change-Id: I6ec2b168379de8c89bb0e56ff4fae4c84edcf2cd
Note to 3.3 canary users: It might take one or two canaries for the last fix to propagate to 3.3, ETA is 3.3.0-alpha-06.
Note to 3.3 canary users: It might take one or two canaries for the last fix to propagate to 3.3, ETA is 3.3.0-alpha-06.
lo...@gradle.com
This is excellent news indeed!
ta...@gmail.com
🎉🎉🎉
hu...@google.com
Update: This issue will be completely fixed in 3.2.0-rc01 and 3.3.0-alpha07.
[Deleted User] <[Deleted User]>
nice
vi...@gmail.com
nice
Description
- AndroidJavaCompile.dataBindingDependencyArtifacts is missing a `@PathSensitive` annotation, so it's treated as `ABSOLUTE` (this is tracked in
- A number of absolute paths are specified as annotation processor parameters in `options.compilerArgs`:
- -Aandroid.databinding.minApi=26
- -Aandroid.databinding.enableDebugLogs=0
- -Aandroid.databinding.sdkDir=/Users/lptr/Library/Android/sdk
- -Aandroid.databinding.bindingBuildFolder=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/data-binding-compiler/debug
- -Aandroid.databinding.enableForTests=0
- -Aandroid.databinding.modulePackage=org.gradle.android.example.library
- -Aandroid.databinding.generationalFileOutDir=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/bundles/debug/data-binding
- -Aandroid.databinding.xmlOutDir=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/data-binding-info/debug
- -Aandroid.databinding.artifactType=LIBRARY
- -Aandroid.databinding.printEncodedErrors=0
- -Aandroid.databinding.isTestVariant=0
- -Aandroid.databinding.exportClassListTo=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/data-binding-info/debug/_generated.txt
- A source file is generated called `DataBindingInfo.java` with a random UUID that changes every time a new file is generated:
package android.databinding.layouts;
import android.databinding.BindingBuildInfo;
@BindingBuildInfo(buildId="9dfdb009-9c54-4b16-8df1-956cd6e00303")
public class DataBindingInfo {}