api

Split off value snapshotting and attributes related methods of TestUtil

Warn with Ivy publish and incompatible features

Features like constraints, platforms or declared capabilities are not

supported in the ivy.xml file format.

Issue #3667

Rework task dependency inference so that `Provider` implementations use the same `TaskDependencyContainer` interface that most other things use to declare their producer task to the task resolution infrastructure, rather than having special knowledge sprinkled around various places.

Cleaned up a bunch of `Provider` and `Property` implementations so that more logic is reused rather than reimplemented.

Support propagation of the producer task for provider instances that are created using `Provider.map()`.

Now, when a provider represents a task or task output, whether mapped or not, that task is taken as the producer of the value and the mapping function is not called. Otherwise, the value of the provider is unpacked and resolved, as it previously was.

Rework the protocol by which providers communicate their build dependencies to consumers.

Replace internal `SourceDirectorySetFactory` with a method on public `ObjectFactory` service, to allow plugins to create instances of this type without resorting to using internal types.

Separate 'prefer' and 'require' in dependency versions

When we introduced the ability to declare a 'preferred' version on

a dependency declaration, this was implemented such that declaring

a "required" dependency version using `org:foo:1.0` was effectively

the same as declaring a "preferred" version `org:foo { prefer '1.0' }`.

In order to differentiate between the behaviour of required and

preferred dependency versions, this commit introduces a separate

model for these constraint types. This model is published to

Gradle `.module` metadata files, and is retained internally

throughout dependency resolution.

At this stage, the behaviour of required and preferred versions

is identical. A later commit will introduce the behavioural

difference.

Add dedicated DSL to customize Ivy descriptor to ivy-publish plugin

This commit adds a type safe DSL for customizing the generated Ivy

module descriptor of an IvyPublication to the ivy-publish plugin:

descriptor {

license {

name = 'The Apache License, Version 2.0'

url = 'http://www.apache.org/licenses/LICENSE-2.0.txt'

}

author {

name = 'Jane Doe'

url = 'http://example.com/users/jane'

}

description {

text = 'A concise description of my library'

homepage = 'http://www.example.com/library'

}

}

Only interfaces are exposed as part of the public API, all of them are

prefixed with `IvyModuleDescriptor`. The exposed properties make use of

the Provider API.

In addition, the new DSL is documented in the User Guide, DSL Reference

and Release Notes.

Resolves #5193.

Dogfood ImmutableFileCollection on production code (#4988)

This reverts commit 13eaebc2b1244511dcbff4c59cd41253e3b69642.

Dogfood ImmutableFileCollection on production code (#4988)

Use ImmutableFileCollection in production code

Remove model rules from ivy-publish plugin

Make IvyArtifact lazy

Delegate artifact creation to Publication

Issue: #4943

Fix build

Dogfood ImmutableFileCollection in tests (#4972)

Reduce the number of static factory methods from ImmutableFileCollection

Use layout.fileFor() in a smoke test

Do not add module metadata file to publishable files if deactivated (#4776)

Fixes #4760

Changed the 'swiftpm-export' plugin to reuse the same service to map a project dependency to a Swift PM target, as is used by the other publishing plugins to map a project dependency to a GAV.

Fix ignored tests, take 2

Revert "Fix ignored tests"

Fix ignored tests

Ignore failing tests temporarily

Re-use `TaskDependencyResolveContext` during task graph building (#3807)

All dependency resolution in Gradle should happen via TaskDependencyResolveContext during when building the task graph. Calling `DefaultTaskDependency.getDependencies(task)` should be avoided since it creates a new `TaskDependencyResolveContext` and needs to calculate the dependencies again.

`SkipTaskWithNoActionsExecuter` now re-uses the `TaskExecutionGraph` to determine the dependencies of a task instead of re-evaluating them.

After this commit, the task properties are resolved at three places:

- When building the task graph for walking the input files

- When checking if there a task can be executed in parallel with the currently running tasks based on on the declared outputs, destroyables and task local state

- For using the task properties during task execution

The last two places could still be unified into one, but that seems to be a little bit more complicated.

Rename 'experimental features' to 'feature previews'

The idea behind this is that we have a set of feature previews rather

than one cryptic experimental flag.

A feature preview collects a set of related functionality (e.g.

everything related to gradle metadata) that changes existing behavior

and thus could potentially break existing builds. The preview options

will be removed with the next major release (currently 5.0) and the new

behaviour will then become the default.

Signed-off-by: Jendrik Johannes <jendrik@gradle.com>

Initial implementation of component metadata rules allowing modification of variant attributes

This commit introduces metadata rules that support modification of variant attributes. Variant attributes

are specific to each variant and can be found in module metadata. Those are NOT component level attributes,

which could be used during dependency resolution. This will be added in a subsequent commit.