Status Update
Comments
je...@google.com <je...@google.com>
al...@google.com <al...@google.com> #2
Should we transform it from
fun <FileTypeT: FileSystemLocation> add(
type: MultipleArtifact<FileTypeT>,
artifact: FileTypeT
)
to
fun <FileTypeT: FileSystemLocation, Appendable> add(
type: MultipleArtifact<FileTypeT>,
artifactProvider: Provider<FileTypeT>
)
should we also share with Artifacts interface: ArtifactsImpl.appendTo ArtifactsImpl.appendAll. They are not in use right now. Maybe part of another ticket?
je...@google.com <je...@google.com> #3
I don't think we can just move it to use a Provider<> as the original bug called for adding a file.
plus this add() would become just like to OperationRequest::toAppendTo no ?
al...@google.com <al...@google.com> #4
So we somehow need to disallow calling this method if FileSystemLocation is produced by task?
Can we add some validation on build phase - meaning we can call those only during config but not when tasks execute?
plus this add() would become just like to OperationRequest::toAppendTo no ?
it looks like it
al...@google.com <al...@google.com> #5
Initial ticket that introduced Artifacts.add is
al...@google.com <al...@google.com>
al...@google.com <al...@google.com>
an...@google.com <an...@google.com> #6
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Jellyfish | 2023.3.1 Canary 7
- Android Gradle Plugin 8.4.0-alpha07
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
Description
The API : fun <FileTypeT: FileSystemLocation> add( type: MultipleArtifact<FileTypeT>, artifact: FileTypeT )
is really problematic for several reason :
We should consider restricting this API by maybe moving to a different ArtifactType like a SourceArtifactType since people use it to add folder/file that are not generated, they are essentially source files.