Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce VersionMapping support for IvyPublication

Signed-off-by: Roberto Perez Alcolea <rperezalcolea@netflix.com>

  1. … 7 more files in changeset.
Introduce VersionMapping support for IvyPublication

Signed-off-by: Roberto Perez Alcolea <rperezalcolea@netflix.com>

  1. … 7 more files in changeset.
Add task to publish all publications to a single Ivy repository

Similarly to the task added for Maven repositories

Fixes #8509

  1. … 1 more file in changeset.
Implement Gradle metadata marker in published pom/ivy files

This commit implements a performance optimization for Gradle metadata.

Given that today there's no library published in any repository with

Gradle metadata, it's much more likely to find a POM (or Ivy) metadata

file for an external dependency, rather than a Gradle metadata file.

If we decided to add `gradleMetadata()` sources by default to all

repositories, then we would probably introduce a performance regression

to a lot of builds, because we would first try to get Gradle metadata,

then fail, and search for POM/Ivy files.

To avoid this, whenever a library is going to be published with Gradle

metadata, we will introduce a _marker_ in the published POM or Ivy

file. When Gradle _resolves_ such a dependency, it will parse the POM

file and look for the marker. If it finds it, then it will _redirect_

to use Gradle metadata instead. This means that when Gradle metadata is

present, we will pay the price of looking for a POM or Ivy file first,

start parsing, only to discover we should parse Gradle metadata. This

should be ok in the beginning, knowing that if `gradleMetadata()` is

added, then we would systematically look at Gradle metadata first.

This means that this is a _temporary_ solution, until Gradle metadata

becomes widespread. So "temporary" should be understood as several

months, if not years.

The marker introduced in POM and Ivy files is _neutral_ for both Ivy

and Maven. By this we mean that it uses an XML comment. While not super

nice, we couldn't use a custom namespace because both Ivy and Maven

fail when parsing this. Properties were considered too, but Ivy doesn't

support them so for consistency both models use comments.

It's worth noting that we will still _completely parse_ the POM or Ivy

descriptor. It's a waste of time, but it helps in case we find a marker

but that for some reason the Gradle metadata file is absent. In this

case we fallback on the model we found.

This change also introduces a change in the semantics of the incubating

metadata sources API: those should be considered _hints_, and not strong

statements anymore.

Finally, should a producer want to avoid publishing Gradle metadata,

it's now possible to disable the task that creates the metadata file.

  1. … 56 more files in changeset.
Use public services in native plugins to construct `FileCollection` instances, rather than using internal `FileOperations`.

  1. … 32 more files in changeset.
Use public services in native plugins to construct `FileCollection` instances, rather than using internal `FileOperations`.

  1. … 32 more files in changeset.
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

  1. … 3 more files in changeset.
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.

  1. … 16 more files in changeset.
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).

  1. … 125 more files in changeset.
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.

  1. … 60 more files in changeset.
Remove some direct usages of `AsmBackedClassGenerator` from tests, and instead use `TestUtil` fixture to take care of setting up a decorating `Instantiator`.

  1. … 17 more files in changeset.
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

  1. … 122 more files in changeset.
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.

  1. … 26 more files in changeset.
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.

  1. … 26 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

  1. … 63 more files in changeset.
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

  1. … 2 more files in changeset.
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.

  1. … 29 more files in changeset.
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.

  1. … 33 more files in changeset.
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.

  1. … 44 more files in changeset.
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.

  1. … 36 more files in changeset.
Use `getVersion()` in preference to `getVersionConstraint().getPreferredVersion()`

  1. … 13 more files in changeset.
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.

  1. … 29 more files in changeset.
Dogfood ImmutableFileCollection on production code (#4988)

This reverts commit 13eaebc2b1244511dcbff4c59cd41253e3b69642.

  1. … 88 more files in changeset.
Revert "Dogfood ImmutableFileCollection on production code (#4988)"

This reverts commit 834632674ca29b6fd190857947338b2b54a9bb62.

The commit caused a bug in incremental compilation, causing changes

to go undetected.

  1. … 88 more files in changeset.
Dogfood ImmutableFileCollection on production code (#4988)

Use ImmutableFileCollection in production code

  1. … 88 more files in changeset.
Remove model rules from ivy-publish plugin

  1. … 5 more files in changeset.
Make IvyArtifact lazy

  1. … 11 more files in changeset.
Make Ivy project identity live

  1. … 2 more files in changeset.
Delegate artifact creation to Publication

Issue: #4943

  1. … 34 more files in changeset.
Remove special treatment for Gradle module descriptor from Ivy publishing

Issue: #4943

  1. … 4 more files in changeset.