https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# configuration-cache
s
This message was deleted.
c
I have to use that 
BuiltArtifactsLoader
to load the file because it knows which file in the Directory I want, and it's how AGP API is designed to be used. The 
testApkDir
doesn't exist until other tasks are executed ( in this case 
packageDebugAndroidTest
)
p
The stacktrace might help understand
c
As I'm using "--configuration-cache-problems=warn" the --dry-run is successful
removing that flag, ouch:
Cannot convert path to File. path='() -> kotlin.String?'
java.lang.NullPointerException (no error message)
Cannot convert path to File. path='() -> kotlin.String?'
java.lang.NullPointerException (no error message)
p
problems=warn is bad for debugging problems
Seems like some kotlin function is problematic
c
in any case... I changed some 
file { builtArtifactsLoader.load(apk)?.elements?.single()?.outputFile }
to: 
file(builtArtifactsLoader.load(apk)!!.elements.single().outputFile)
and now it's only: 
java.lang.NullPointerException (no error message)
So it seems like something it's called too early, I would say it changes when CC is enabled
that 
testApk
is a @InputFile @Classpath so I can understand it's needed
(I have another test that verifies the task is cacheable without CC and works fine)
Let me share another simpler case:
Copy code
appApk.set { copySmallApp.destinationDir.listFiles()!!.single() }
and the error:
Copy code
Configuration cache state could not be cached: field '__appApk__' from type 'FlankYmlWriterTask': error writing value of type 'org.gradle.api.internal.file.DefaultFilePropertyFactory$DefaultRegularFileVar'
> copySmallApp.destinationDir.listFiles() must not be null
again, without CC everything works
(in this case I have a 
dependsOn(copySmallApp)
)
p
What's the type returned by load(apk) ?
c
Android one, some kind of Artifact?
But the last example with a Copy task should be easier to reason about, even if it's a different error, it seems the same reason, early evaluation
p
Indeed, it realizes outputs eagerly
You should start from a TaskProvider for copySmallApp instead
And map
Plain providers are realized when storing cc, wiring providers all the way is the way to go
c
Then for the Android case I don't have an option
p
Because ? Sorry but I'm on the go and can't really browse the related code to understand it all
c
I don't have the TaskProvider, AGP gives me a Property<Directory> and a class that can extract a File from it
I can wait until tomorrow if you need ( or even make the repo public, but it's not so small)
p
Assuming the Property<Directory> provided by AGP has proper task dependency information then you should .map{} it
c
And I do, but you can see in the first message how it doesn't work...
p
Right
Copy code
testApk.value(testApkDir.map {
  it.file(builtArtifactsLoader.load(it)!!.elements.single().outputFile)
})
Isn't it the 
load(it).elements.single
call that is too eager? What's the type of elements?
c
I'm now with the kid... But yes, I expected the load to be executed later, buildArtifactsLoader expects to be execute after the testApkDir provider task
Without CC load is executed later
p
I would ask to the Android folks
c
They suggested (in their samples) to give both the Provider<Directory> and the BuildArtifactsLoader to the task, and call the load in the task execution, but then I can't use the APK as a Classpath...well I guess I can use the Provider<Directory> but then id there is any change in the metadata the buildcache would by invalidated...
If I try to annotate as InputFile a method that gets the APK I will have the same issue
I guess I could ignore the BuildArtifactsLoader..and simply filter in Provider<Directory> for any file with APK extension...
p
This all makes sense. It is not ideal
Is the metadata changing that much to make the lack of input precision a problem?
c
No idea, i don't think it's even documented
p
In general I'd say that a good move would be that AGP provides a proper output for just the APK if it's a common use case
c
Sure, but that's not what I can decide
p
🙂
You could report your use case to the Android folks
In the meantime their recommendation sounds reasonable to me
c
I'll try, thanks But.. didn't you say a Provider is always executes early unless is a TaskProvider?
p
I said a plain provider. Lemme clarify
I meant "a provider with no task dependencies attached"
One example is using 
providers.provider {}
c
Oooki
It's clear now, thanks
p
Cool
c
In case you wonder...everything fixed.. For Copy task... I have created MyCopyTask, using 
FileSystemOperations
and declaring an output (
@OutputFile Provider<RegularFile>
) I don't love it because copy is always a directory (with type 
File
.. I guess if it was a 
Property<Directory>
I wouldn't need to create my task For the 
apk
file..I'm using the `Provider<Directory>`and also it seems the BuildCache works fine (I wonder if it's relocatable, but I still have to try it)
👍 1
3 Views
Open in Slack
PreviousNext
Powered by