org

Use public services in native plugins to construct `FileCollection` instances, rather than using internal `FileOperations`.

Add warning for dependency with attributes

Neither Ivy nor Maven support attributes so having attributes defined on

a dependency declaration now produces a warning as well.

Issue #3667

Remove `getUsage` from `UsageContext`

This `Usage` is an artifact of migration. `UsageContext` is mostly representing

what an outgoing published variant is, but this `Usage` is preventing us from

doing smarter things. What we really care about is the attributes of published

variants, and their name for publication.

Allow the services required by a given class to be queried prior to creating any instances of that class. Use this to allow `ArtifactTransformDependencies` to be injected into artifact transforms using any of the service injection patterns (that is, via a constructor or a getter).

Replace most direct usages of `DirectInstantiator` with indirect usages via `InstantiatorFactory` or test fixtures instead. This means more consistent behaviour in unit tests because the objects under test will behave more similarly to how they do at runtime. This also allows the decision of how the instantiation should behave to live in as few places as possible, so this can be more easily evolved and contextualized.

Remove some direct usages of `AsmBackedClassGenerator` from tests, and instead use `TestUtil` fixture to take care of setting up a decorating `Instantiator`.

Decorate all domain collection container for emitting build ops (#7876)

* Update all domain object container with decorator for tracing executed callback actions

* Add decorator to a ll required occurances of DefaultDomainObjectSet

* Keep ctor for DefaultPolymorphicDomainObjectContainer as its used in gradle-idea-ext plugin

* Bring back DefaultDomainObjectSet constructor used by the android plugin

* keep backwards compatibility

Make AbstractArchiveTask.destinationDir mandatory

Prior to this commit the working directory was used when the

`destinationDir` was not set. Since this behavior does not play nice

with reproducible builds, it will now fail instead. However, it should

rarely happen because the `base` plugin provides a convention.

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.