Package com.palantir.gradle.dist.service
Class DiagnosticsManifestPlugin
java.lang.Object
com.palantir.gradle.dist.service.DiagnosticsManifestPlugin
- All Implemented Interfaces:
org.gradle.api.Plugin<org.gradle.api.Project>
public final class DiagnosticsManifestPlugin
extends Object
implements org.gradle.api.Plugin<org.gradle.api.Project>
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionvoidapply(org.gradle.api.Project project) This plugin uses a few slightly 'advanced' gradle features: - "attributes" (https://docs.gradle.org/current/userguide/variant_attributes.html) - "artifact transforms" (https://docs.gradle.org/current/userguide/artifact_transforms.html) These seem to be the new idiomatic way of doing things (and Gradle uses them _heavily_ internally, e.g.
-
Constructor Details
-
DiagnosticsManifestPlugin
public DiagnosticsManifestPlugin()
-
-
Method Details
-
apply
public void apply(org.gradle.api.Project project) This plugin uses a few slightly 'advanced' gradle features: - "attributes" (https://docs.gradle.org/current/userguide/variant_attributes.html) - "artifact transforms" (https://docs.gradle.org/current/userguide/artifact_transforms.html) These seem to be the new idiomatic way of doing things (and Gradle uses them _heavily_ internally, e.g. to delineate the 'api' vs 'implementation' stuff in theJavaPlugin). They let us declaratively express things in a _really_ nice way, with beautiful granular caching etc. See https://docs.gradle.org/current/userguide/variant_model.html for some helpful diagrams. Also try running `./gradlew outgoingVariants` on a project to visualize what's going on. We define a couple ofTransformActions so that when we define that we want just an extracted file, and gradle has all these jars and resources, it can use the right TransformAction to bridge the gap.- Specified by:
applyin interfaceorg.gradle.api.Plugin<org.gradle.api.Project>
-