Currently we have a dirty assumption that every subproject (module) in a consumer's Gradle build aside from the app module and the builder module should contribute resources to the app module (from the common and target source sets).
This is gross.
We should be leveraging dependencies in the MPP plugin's model to get the right resources.
This will ensure sanitized builds and enable consumers to have multiple apps in a single gradle multi-project.
[ ] Must be deterministic
[ ] Must merge in a way such that consumers can override individual provided resources (aka, be able to override an individual file within the 'basic' resource pack found in the starter resources bundle artifact) prior to them being packed.
NOTE
TLDR, please do not mirror the way the MPP plugin handles resources. Instead, if possible, register the resource directories /as/ resource directories.
MPP resource handling does not seem to add common module resource directories as resource directories of its targets. Right now, benefits of this are unclear to me. Instead, they simply have the processResources task take two inputs. To me this is a poor solution as it buries model information in implementation details. Tasks can change from build to build, consumers can rename them, and they require identification based on class+name (string). Task configuration provided by a plugin that is required to execute after project evaluation would break if consumers wanted to rename their task (which typically takes place during the task configuration phase, prior to after evaluation action execution).
Currently we have a dirty assumption that every subproject (module) in a consumer's Gradle build aside from the app module and the builder module should contribute resources to the app module (from the common and target source sets).
This is gross.
We should be leveraging dependencies in the MPP plugin's model to get the right resources. This will ensure sanitized builds and enable consumers to have multiple apps in a single gradle multi-project.
NOTE TLDR, please do not mirror the way the MPP plugin handles resources. Instead, if possible, register the resource directories /as/ resource directories.
MPP resource handling does not seem to add common module resource directories as resource directories of its targets. Right now, benefits of this are unclear to me. Instead, they simply have the processResources task take two inputs. To me this is a poor solution as it buries model information in implementation details. Tasks can change from build to build, consumers can rename them, and they require identification based on class+name (string). Task configuration provided by a plugin that is required to execute after project evaluation would break if consumers wanted to rename their task (which typically takes place during the task configuration phase, prior to after evaluation action execution).