You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The osdetector-gradle-plugin is a thin wrapper built on top of this plugin for Gradle users. It has been a handy tool built into many other Gradle plugins, such as the protobuf-gradle-plugin, which needs OS information to determine and resolve a platform-dependent artifact (protoc).
Gradle is rolling out its configuration caching feature, which persists build configurations to the disk and can be loaded and executed instantly next time if the build configuration has not change. In order to be compliant with this feature, plugins are not allowed to perform direct system property/file read at the configuration phase (see Gradle configuration cache requirements). Instead, Gradle provides several Provider APIs for doing such at the configuration phase in a configuration cache compliant way.
Request of changes:
We want this plugin to abstract and expose an interface for system property/file operations, so that it allows wrapper plugins to override/inject code for performing system property/file operations in their own way.
Would you accept a PR for such changes? I've create one in #47, please let me know or comment on the PR if you have any concerns.
The text was updated successfully, but these errors were encountered:
Creates interfaces for abstracting away system property and file
operations. Wrapper plugins can inject their own code for
performing those operations in ways compliant to the
environment/tool.
See details in #48.
Context:
The osdetector-gradle-plugin is a thin wrapper built on top of this plugin for Gradle users. It has been a handy tool built into many other Gradle plugins, such as the protobuf-gradle-plugin, which needs OS information to determine and resolve a platform-dependent artifact (protoc).
Gradle is rolling out its configuration caching feature, which persists build configurations to the disk and can be loaded and executed instantly next time if the build configuration has not change. In order to be compliant with this feature, plugins are not allowed to perform direct system property/file read at the configuration phase (see Gradle configuration cache requirements). Instead, Gradle provides several
Provider
APIs for doing such at the configuration phase in a configuration cache compliant way.Request of changes:
We want this plugin to abstract and expose an interface for system property/file operations, so that it allows wrapper plugins to override/inject code for performing system property/file operations in their own way.
Would you accept a PR for such changes? I've create one in #47, please let me know or comment on the PR if you have any concerns.
The text was updated successfully, but these errors were encountered: