Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Revert some changes to artifact transform execution, as these changes introduce a performance regression.

    • -13
    • +7
    ./ComponentFileArtifactIdentifierTest.groovy
  1. … 30 more files in changeset.
Merge some logic used for executing a chained scheduled artifact transform node and the other places artifact transforms are executed.

An implication of this change is that when a scheduled transform produces multiple output files, then a consuming scheduled transform will transform those output files in parallel.

    • -7
    • +13
    ./ComponentFileArtifactIdentifierTest.groovy
  1. … 23 more files in changeset.
Implement lenient mode for locking

In lenient mode, lock entries are `requires` and not `strictly` and

there is no validation after resolution. This allows deviations from the

lock state.

Issue #9907

    • -8
    • +9
    ./RootLocalComponentMetadataTest.groovy
  1. … 8 more files in changeset.
Implement strict mode for locking

In strict mode, a locked configuration without a lockfile, empty or not,

is illegal and will cause the build to fail.

Issue #9907

    • -3
    • +4
    ./RootLocalComponentMetadataTest.groovy
  1. … 12 more files in changeset.
Add deprecation mechanism for configurations

    • -7
    • +7
    ./DefaultLocalComponentMetadataTest.groovy
    • -1
    • +1
    ./RootLocalComponentMetadataTest.groovy
  1. … 15 more files in changeset.
Rework exclude rule merging

As a follow-up to #9197, this commit properly fixes the

exclude rule merging algorithm, by completely rewriting

it. The new merging algorithm works by implementing the

minimal set of algebra operations that make sense to

minimize computation durations. In order to do this,

this commit introduces a number of exclude specs

(found in their own package) and factories to create

actual implementation of those specs.

Specs represent the different kind of excludes we can

find:

- excluding a group

- excluding a module (no group defined)

- excluding a group+module

- excluding an artifact of a group+module

- pattern-matching excludes

- unions of excludes

- intersections of excludes

With all those minimal bricks, factories are responsible

of generating consistent specs. The dumbest factory

will just generate new instances for everything. This

is the default factory.

Minimally, this factory has to be backed by an optimizing

factory, which will take care of handling special cases:

- union or intersection of a single spec

- union or intersection of 2 specs

- when one of them is null

- when both are equal

Then we have a factory which performs the minimal algebra

to minimize specs:

- unions of unions

- intersections of intersections

- union of a union and individual specs

- insection of an intersection and individual spec

- ...

This factory can be as smart as it can, but one must be

careful that it's worth it: some previously implemented

optimizations (like (A+B).A = A turned out to be costly

to detect, and didn't make it the final cut.

Last but not least, a caching factory is there to avoid

recomputing the same intersections and unions of specs

when we have already done the job. This is efficient if

the underlying (delegate) specs are easily compared,

which is the case thanks to the interning factory.

All in all, the delegation chain allows us to make

the algorithm fast and hopefully reliable, while

making it easier to debug.

    • -3
    • +0
    ./DefaultLocalComponentMetadataTest.groovy
  1. … 75 more files in changeset.
Support requested capabilities on external dependencies

This commit adds support for having requested capabilities

part of the module component selector, for external dependencies.

This means that if a component is using Gradle metadata, we can

read requested capabilities and honor them during selection.

This reworks where requested capabilities are stored, and in

particular moves them to the `ComponentSelector`, making them

properly part of the identity of a dependency. As such, two

dependencies requiring two different variants by using distinct

capabilities will now properly appear as two different dependencies

in the dependency graph, instead of two variants of the same

dependency.

    • -2
    • +2
    ./DefaultProjectComponentSelectorTest.groovy
  1. … 63 more files in changeset.
Add support for enforced local platforms

This commit reworks the Java Platform plugin so that we can

also support _enforced_ local platforms, in order to be

consistent with externally, enforced platforms (BOM or Gradle).

    • -2
    • +2
    ./DefaultLocalComponentMetadataTest.groovy
  1. … 7 more files in changeset.
Use an `ImmutableSet` to represent the configuration hierarchy

ImmutableSets are ordered and optimized for lookups. We happen to

call `contains` a lot on hierarchies, so using a `Set` should

optimize things a little.

    • -7
    • +8
    ./DefaultLocalComponentMetadataTest.groovy
    • -1
    • +2
    ./RootLocalComponentMetadataTest.groovy
  1. … 30 more files in changeset.
Normalize `ModuleIdentifier`

This commit reworks the `ComponentModuleIdentifier`/`ComponentModuleSelector`/`ModuleVersionSelector`

classes to use `ModuleIdentifier` under the hood, instead of storing denormalized strings. This has

the advantage that we can reduce the use of the module identifier factory, which is called very

often during dependency resolution. Sharing instances reduces the need for conversions, and makes

comparisons faster.

    • -1
    • +2
    ./DefaultLibraryComponentSelectorTest.groovy
    • -1
    • +2
    ./DefaultProjectComponentSelectorTest.groovy
    • -3
    • +6
    ./RootLocalComponentMetadataTest.groovy
  1. … 162 more files in changeset.
Fix reason for lock constraints

    • -0
    • +22
    ./RootLocalComponentMetadataTest.groovy
  1. … 1 more file in changeset.
Use ModuleComponentIdentifier for locked dependencies

This is a pure refactoring that changes `DependencyLockingState` to

represent locked dependencies as `ModuleComponentIdentifier` instead of

as `DependencyConstraint` instances. This decouples the state from the

actual locking implementation, and removes the use of

`VersionConstraint.getPreferredVersion()` in order to map the state to

actual selectors in the graph.

    • -3
    • +3
    ./RootLocalComponentMetadataTest.groovy
  1. … 8 more files in changeset.
Add support for dependency attributes on project dependencies

There was an inconsistency with dependency attributes, that could be used to

select an external dependency, but not a project dependency. This commit aligns

what is possible for both.

    • -2
    • +3
    ./DefaultProjectComponentSelectorTest.groovy
  1. … 15 more files in changeset.
Change `ProjectComponentIdentifier` and `ProjectComponentSelector` implementations to carry enough information to report the correct display name and project name. Change more places to delegate to the `BuildState` for a particular build to determine these values for a given project, rather than duplicating the logic to calculate these things.

    • -31
    • +12
    ./DefaultProjectComponentSelectorTest.groovy
  1. … 43 more files in changeset.
Make locking constraints non transitive

Having them transitive could bring back excluded modules.

    • -0
    • +16
    ./RootLocalComponentMetadataTest.groovy
  1. … 2 more files in changeset.
Use the `BuildIdentifier` that was assigned to a build when it was registered to refer to that build is most places.

- The build identifier was previously being unpacked to a name string in a few places and recreated from this, potentially losing some context and making too many assumptions about the uniqueness of the name.

- The project dependencies in `LocalComponentMetadata` are no longer transformed to map the build identifier to a "foreign" build identifier. The original build identifier is used instead.

- A "foreign" build identifier is still included in the `LocalComponentMetadata` to make the `isCurrentBuild()` work correctly in the resolution result. This method should go away at some point or at least the "foreign" build identifier should move closer to the result implementation rather than living in the metadata.

    • -1
    • +2
    ./DefaultProjectComponentSelectorTest.groovy
  1. … 22 more files in changeset.
Move a service implementation into core to live with the service interface, as this service no longer represents a composite build specific view of the projects in the build tree.

    • -91
    • +0
    ./DefaultProjectComponentIdentifierTest.groovy
  1. … 22 more files in changeset.
Enable updating a subset of locked dependencies

The feature is triggered by the "--update-locks org:foo,org:bar" command

line flag.

This filters out the constraints for dependencies to update and applies

the other constraints as "prefer" instead of "strict".

Fixes #4906

    • -2
    • +2
    ./RootLocalComponentMetadataTest.groovy
  1. … 14 more files in changeset.
Refactorings following review comments

* Rename LockConstraint to DependencyLockingState

* Removed EmptyLockConstraint

* Simplified some nested conditionals

    • -4
    • +3
    ./RootLocalComponentMetadataTest.groovy
  1. … 14 more files in changeset.
Avoid accessing `ResolutionStrategy` for non-root components

To determine if a configuration should have dependency locking enabled,

we inspect the ResolutionStrategy for that configuration. However, we

were needlessly inspecting this for configurations in referenced

projects, leading to added contention.

With this change, we only inspect the resolution strategy for

configurations when building the component metadata for the root

component, not for any referenced project components.

    • -7
    • +7
    ./DefaultLocalComponentMetadataTest.groovy
    • -5
    • +4
    ./RootLocalComponentMetadataTest.groovy
  1. … 11 more files in changeset.
Lock validation and persist through graph visitor

This introduces validation of graph resolution with the lock file.

Added or missing dependencies in the graph compared to the lock

file cause a failure.

The visitor doing the validation is also used for trigerring

the persistence of the result.

Fixes #4862

    • -2
    • +4
    ./RootLocalComponentMetadataTest.groovy
  1. … 28 more files in changeset.
Changes following code review

Issue #3182

* More specific reason added to generated constraint

* Moved code around and improved naming

* Perform mutation validation on DefaultResolutionStrategy

    • -2
    • +2
    ./RootLocalComponentMetadataTest.groovy
  1. … 9 more files in changeset.
Leverage injection for DependencyLockingProvider

Issue #3182

    • -1
    • +1
    ./DefaultLocalComponentMetadataTest.groovy
    • -3
    • +3
    ./RootLocalComponentMetadataTest.groovy
  1. … 8 more files in changeset.
Use ResolutionStrategy as entry point to active locking

Issue #3182

    • -6
    • +6
    ./DefaultLocalComponentMetadataTest.groovy
  1. … 13 more files in changeset.
Introduce dependency-locking

Issue #3182

    • -0
    • +51
    ./RootLocalComponentMetadataTest.groovy
  1. … 21 more files in changeset.
Introduce `CapabilitiesExtension`

This commit adds a capabilities extension which can be applied to a project. If it's added, local

components gain the ability to declare capabilities. Currently, only the `java-library` plugin

supports capabilities, but it's expected that more plugins will add it (for example, the native

plugin), which explains why the extension lives in `core`.

When a project declares capabilities, they are bound to configurations. This lets us fail whenever

a local component capability conflicts with a transitive module capability. It will also let us

publish capabilities for local components in a subsequent commit.

    • -7
    • +8
    ./DefaultLocalComponentMetadataTest.groovy
  1. … 16 more files in changeset.
Revert the initial implementation of capabilities

Revert "Remove the `Preference` inner class"

Revert "Add test case showing limitation of the current implementation of capabilities"

Revert "Report error whenever two modules in the graph disagree on a preference"

Revert "Support capabilities with project dependencies"

Revert "Consume capabilities from external modules"

Revert "Handle case of conflicting resolution in case multiple capabilities are found"

Revert "Make sure that conflict resolution on version still kicks in"

Revert "Wire capabilities handling into conflict resolution"

Revert "Introduce `CapabilitiesHandlerInternal`"

Revert "Validate module notations in capabilities"

Revert "Introduce the concept of "capabilities""

This reverts commit a6248b2c4e7a810051112fc2169c97d341b9f007.

This reverts commit 76e88732f403d1b295c879bdee0b0a92887e4173.

This reverts commit d9dbe0f6d909604d31857504133440f92996d3f3.

This reverts commit ac3ffa467dd73314b4526b79df3cedf6db4e6c13.

This reverts commit 97f523cd78cdca3819a8a6d65d33b72f8b972646.

This reverts commit d4c02e3f13340ce2d6114cd17f741ac51fee7796.

This reverts commit 4d4d71eb26a2828ff37fe700ae55530d9fff711d.

This reverts commit b0c962468a54affd3eaad8a5df698287d5a1ab4f.

This reverts commit 4030f642397f46330670b99cd6252e92684c53a1.

This reverts commit 80f39f5465990c870dac59b61ade4d8c68839fe2.

This reverts commit 8c0e02833303ea1a6a4e57af48278f24672c98ff.

    • -2
    • +1
    ./DefaultLocalComponentMetadataTest.groovy
  1. … 64 more files in changeset.
Moved responsibility for determining the `BuildIdentifier` for a build into core, from dependencyManagement project, and changed the logic to always produce the same identifier for a given build. Previously, the id could change based on _when_ the id was queried. For example, any kind of dependency resolution in an init script would lead to all build having `:` as their build id.

In this change the build id for all nested builds is calculated based on the root directory of the build.

    • -1
    • +1
    ./DefaultProjectComponentIdentifierTest.groovy
  1. … 20 more files in changeset.
Support capabilities with project dependencies

Previously, it was possible to discover and solve conflicts between published modules, or through the `capabilities` block when

declaring capabilities for external modules. With this commit, it is now possible to declare capabilities in projects that are

used during conflict resolution.

    • -1
    • +2
    ./DefaultLocalComponentMetadataTest.groovy
  1. … 29 more files in changeset.
Removed `BuildIdentifier.isCurrentBuild()`, as this represents _state_ about a build that depends on where the build is being observed from and which prevents a `BuildIdentifier` instance being used as an _identifier_ for the build.

    • -2
    • +2
    ./DefaultProjectComponentIdentifierTest.groovy
  1. … 7 more files in changeset.