Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -3
    • +2
    ./ComponentSelectorSerializerTest.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -3
    • +2
    ./ComponentSelectorSerializerTest.groovy
  1. … 79 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -3
    • +2
    ./ComponentSelectorSerializerTest.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -3
    • +2
    ./ComponentSelectorSerializerTest.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -3
    • +2
    ./ComponentSelectorSerializerTest.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -3
    • +2
    ./ComponentSelectorSerializerTest.groovy
  1. … 77 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +3
    ./ComponentSelectorSerializerTest.groovy
  1. … 19 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +3
    ./ComponentSelectorSerializerTest.groovy
  1. … 19 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +3
    ./ComponentSelectorSerializerTest.groovy
  1. … 20 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +3
    ./ComponentSelectorSerializerTest.groovy
  1. … 20 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +3
    ./ComponentSelectorSerializerTest.groovy
  1. … 19 more files in changeset.
Add requested attributes to the resolution result

This is done so that it is possible to find out what

attributes were requested/compatible/missing in variants

based on the consumer attributes, without having to

resort on finding the configuration being resolved.

This is mostly useful in build scans where the plugin

listens to every resolution result, but does not necessarily

know what configuration was resolved to generate this

result.

    • -1
    • +12
    ./StreamingResolutionResultBuilderTest.groovy
  1. … 16 more files in changeset.
Add requested attributes to the resolution result

This is done so that it is possible to find out what

attributes were requested/compatible/missing in variants

based on the consumer attributes, without having to

resort on finding the configuration being resolved.

This is mostly useful in build scans where the plugin

listens to every resolution result, but does not necessarily

know what configuration was resolved to generate this

result.

    • -1
    • +12
    ./StreamingResolutionResultBuilderTest.groovy
  1. … 16 more files in changeset.
Provide an API to find what are variant dependencies

The `getDependencies` method on a `ResolvedComponentResult`

mixes all dependencies from all variants together. This

commit provides an alternative method which provides access

to the dependencies _for a specific variant_.

    • -0
    • +1
    ./DefaultResolutionResultBuilderSpec.groovy
  1. … 10 more files in changeset.
Provide an API to find what are variant dependencies

The `getDependencies` method on a `ResolvedComponentResult`

mixes all dependencies from all variants together. This

commit provides an alternative method which provides access

to the dependencies _for a specific variant_.

    • -0
    • +1
    ./DefaultResolutionResultBuilderSpec.groovy
  1. … 10 more files in changeset.
Make selected variant accessible on dependency

For resolved dependency results, we now tell what

is the corresponding selected variant.

    • -13
    • +15
    ./CachingDependencyResultFactoryTest.groovy
    • -13
    • +17
    ./ComponentResultSerializerTest.groovy
    • -2
    • +3
    ./DefaultResolutionResultBuilderSpec.groovy
    • -1
    • +4
    ./DependencyResultSerializerTest.groovy
  1. … 21 more files in changeset.
Make selected variant accessible on dependency

For resolved dependency results, we now tell what

is the corresponding selected variant.

    • -13
    • +15
    ./CachingDependencyResultFactoryTest.groovy
    • -13
    • +17
    ./ComponentResultSerializerTest.groovy
    • -2
    • +3
    ./DefaultResolutionResultBuilderSpec.groovy
    • -1
    • +4
    ./DependencyResultSerializerTest.groovy
  1. … 21 more files in changeset.
Add `strong()` API to version constraints

    • -2
    • +3
    ./ComponentSelectorSerializerTest.groovy
  1. … 16 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
    • -2
    • +2
    ./ComponentSelectorSerializerTest.groovy
    • -3
    • +6
    ./StreamingResolutionResultBuilderTest.groovy
  1. … 23 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
    • -2
    • +2
    ./ComponentSelectorSerializerTest.groovy
    • -3
    • +6
    ./StreamingResolutionResultBuilderTest.groovy
  1. … 25 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
    • -2
    • +2
    ./ComponentSelectorSerializerTest.groovy
    • -3
    • +6
    ./StreamingResolutionResultBuilderTest.groovy
  1. … 25 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
    • -2
    • +2
    ./ComponentSelectorSerializerTest.groovy
    • -3
    • +6
    ./StreamingResolutionResultBuilderTest.groovy
  1. … 25 more files in changeset.
Revert "Deduplicate attributes when writing result to disk"

This reverts commit a9ec4b4afa2a2b2ef208ed7b6d16fa72a6f0c757.

    • -46
    • +0
    ./ComponentSelectorSerializerTest.groovy
  1. … 1 more file in changeset.
Deduplicate attributes when writing result to disk

Serializing attributes (and reading them) can be quite expensive.

In project like Android projects, there are many attributes serialized

and they often have the same values. This prevents overhead by keeping

the serialized values de-duplicated.

    • -0
    • +46
    ./ComponentSelectorSerializerTest.groovy
  1. … 1 more file in changeset.
Deduplicate attributes when writing result to disk

Serializing attributes (and reading them) can be quite expensive.

In project like Android projects, there are many attributes serialized

and they often have the same values. This prevents overhead by keeping

the serialized values de-duplicated.

    • -0
    • +46
    ./ComponentSelectorSerializerTest.groovy
  1. … 1 more file in changeset.
Optimize `ModuleVersionResolveException`

During resolution, we may throw a lot of `ModuleVersionResolveException`

or `ModuleVersionNotFoundException`. Often, one per repository, when

a version is not found in that repository. But in the end, the version

may be found, or a different version may be selected, in which case we

don't care about the failure, which is only used if _no version_ could

be selected.

As a consequence, we had a lot of overhead in both generating a stack

trace **and** an error message, that would never be used.

This commit reworks those special exceptions used during resolution so

that we avoid filling the stack trace (we don't care) and we create

the message lazily (only if it will actually be used).

    • -6
    • +7
    ./CachingDependencyResultFactoryTest.groovy
  1. … 23 more files in changeset.
Optimize `ModuleVersionResolveException`

During resolution, we may throw a lot of `ModuleVersionResolveException`

or `ModuleVersionNotFoundException`. Often, one per repository, when

a version is not found in that repository. But in the end, the version

may be found, or a different version may be selected, in which case we

don't care about the failure, which is only used if _no version_ could

be selected.

As a consequence, we had a lot of overhead in both generating a stack

trace **and** an error message, that would never be used.

This commit reworks those special exceptions used during resolution so

that we avoid filling the stack trace (we don't care) and we create

the message lazily (only if it will actually be used).

    • -6
    • +7
    ./CachingDependencyResultFactoryTest.groovy
  1. … 23 more files in changeset.
Optimize `ModuleVersionResolveException`

During resolution, we may throw a lot of `ModuleVersionResolveException`

or `ModuleVersionNotFoundException`. Often, one per repository, when

a version is not found in that repository. But in the end, the version

may be found, or a different version may be selected, in which case we

don't care about the failure, which is only used if _no version_ could

be selected.

As a consequence, we had a lot of overhead in both generating a stack

trace **and** an error message, that would never be used.

This commit reworks those special exceptions used during resolution so

that we avoid filling the stack trace (we don't care) and we create

the message lazily (only if it will actually be used).

    • -6
    • +7
    ./CachingDependencyResultFactoryTest.groovy
  1. … 24 more files in changeset.
Optimize `ModuleVersionResolveException`

During resolution, we may throw a lot of `ModuleVersionResolveException`

or `ModuleVersionNotFoundException`. Often, one per repository, when

a version is not found in that repository. But in the end, the version

may be found, or a different version may be selected, in which case we

don't care about the failure, which is only used if _no version_ could

be selected.

As a consequence, we had a lot of overhead in both generating a stack

trace **and** an error message, that would never be used.

This commit reworks those special exceptions used during resolution so

that we avoid filling the stack trace (we don't care) and we create

the message lazily (only if it will actually be used).

    • -6
    • +7
    ./CachingDependencyResultFactoryTest.groovy
  1. … 24 more files in changeset.
Optimize `ModuleVersionResolveException`

During resolution, we may throw a lot of `ModuleVersionResolveException`

or `ModuleVersionNotFoundException`. Often, one per repository, when

a version is not found in that repository. But in the end, the version

may be found, or a different version may be selected, in which case we

don't care about the failure, which is only used if _no version_ could

be selected.

As a consequence, we had a lot of overhead in both generating a stack

trace **and** an error message, that would never be used.

This commit reworks those special exceptions used during resolution so

that we avoid filling the stack trace (we don't care) and we create

the message lazily (only if it will actually be used).

    • -6
    • +7
    ./CachingDependencyResultFactoryTest.groovy
  1. … 24 more files in changeset.