You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
gradle-plugins/gradle-plugin-shadow/src/docs/asciidoc/12-controlling-dependencies...

119 lines
4.2 KiB
Plaintext

=== Configuring Shadowed Dependencies
Shadow configures the default `shadowJar` task to merge all dependencies from the project's `runtime` configuration
into the final JAR.
The configurations to from which to source dependencies for the merging can be configured using the `configurations` property
of the link:{api}/tasks/ShadowJar.html[`ShadowJar`] task type.
[source,groovy,indent=0]
----
shadowJar {
configurations = [project.configurations.compile]
}
----
The above code sample would configure the `shadowJar` task to merge depdencies from only the `compile` configuration.
This means any dependency declared in the `runtime` configuration would be **not** be included in the final JAR.
[NOTE]
====
Note the literal use of `project.configurations` when setting the `configurations` attribute of a
link:{api}/tasks/ShadowJar.html[`ShadowJar`] task.
This is **required**. It maybe be tempting to specify `configurations = [configurations.compile]` but this will not
have the intended effect, as `configurations.compile` will try to delegate to the `configurations` property of the
the link:{api}/tasks/ShadowJar.html[`ShadowJar`] task instead of the `project`
====
=== Embedding Jar Files Inside Your Shadow Jar
Because of the way that Gradle handles dependency configuration, from a plugin perspective, shadow is unable to distinguish between a jar file configured as a dependency and a jar file included in the resource folder. This means that any jar found in a resource directory will be merged into the shadow jar the same as any other dependency. If your intention is to embed the jar inside, you must rename the jar as to not end with `.jar` before the shadow task begins.
=== Filtering Dependencies
Individual dependencies can be filtered from the final JAR by using the `dependencies` block of a
link:{api}/tasks/ShadowJar.html[`ShadowJar`] task.
Dependency filtering does **not** apply to transitive dependencies.
That is, excluding a dependency does not exclude any of its dependencies from the final JAR.
The `dependency` blocks provides a number of methods for resolving dependencies using the notations familiar from
Gradle's `configurations` block.
.Exclude an Module Dependency
[source,groovy,indent=0]
----
include::{tests}/FilteringSpec.groovy[tags=excludeDep]
----
.Exclude a Project Dependency
[source,groovy,indent=0]
----
include::{tests}/FilteringSpec.groovy[tags=excludeProject]
----
[NOTE]
====
While not being able to filter entire transitive dependency graphs might seem like an oversight, it is necessary
because it would not be possible to intelligently determine the build author's intended results when there is a
common dependency between two 1st level dependencies when one is excluded and the other is not.
====
==== Using Regex Patterns to Filter Dependencies
Dependencies can be filtered using regex patterns.
Coupled with the `<group>:<artifact>:<version>` notation for dependencies, this allows for excluding/including
using any of these individual fields.
.Exclude Any Version of a Dependency
[source,groovy,indent=0]
----
include::{tests}/FilteringSpec.groovy[tags=excludeDepWildcard]
----
Any of the individual fields can be safely absent and will function as though a wildcard was specified.
.Ignore Dependency Version
[source,groovy,indent=0]
----
shadowJar {
dependencies {
exclude(dependency('shadow:d'))
}
}
----
The above code snippet is functionally equivalent to the previous example.
This same patten can be used for any of the dependency notation fields.
.Ignoring An Artifact Regardless of Group
[source,groovy,indent=0]
----
shadowJar {
dependencies {
exclude(dependency(':d:1.0'))
}
}
----
.Excluding All Artifacts From Group
[source,groovy,indent=0]
----
shadowJar {
dependencies {
exclude(dependency('shadow::1.0'))
}
}
----
==== Programmatically Selecting Dependencies to Filter
If more complex decisions are needed to select the dependencies to be included, the
link:{api}/tasks/ShadowJar.html#dependencies(Action<DependencyFilter>)[`dependencies`] block provides a
method that accepts a `Closure` for selecting dependencies.
.Selecting Dependencies to Filter With a Spec
[source,groovy,indent=0]
----
include::{tests}/FilteringSpec.groovy[tags=excludeSpec]
----