SelectorStateResolverTest.groovy

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).

  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).

  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).

  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).

  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).

  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).

  1. … 77 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 10 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 10 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 11 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 10 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 11 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 10 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 11 more files in changeset.
Delay selection when constraint exists

When a node makes it into the graph, it potentially can transform

pending constraints into valid edges. When that happens, we defer the

selection of the the node so that it happens when the constraint

selector also is known.

In the best case, a fixed version is computed, skipping a dynamic

version resolution. In the worst case, the defer was not needed because

the constraint does not change the selection result.

  1. … 10 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Partial ordering of module selectors

With this commit, we do a partial sort on the selectors, where we place

the dynamic selectors at the end compared to the other ones.

This allows a more efficient resolution in some corner cases but is

mostly preparation work for follow up changes.

  1. … 7 more files in changeset.
Extract type for holding module selectors

Instead of being a list, there is now an object that will be used to

perform some optimisations.

  1. … 3 more files in changeset.
Extract type for holding module selectors

Instead of being a list, there is now an object that will be used to

perform some optimisations.

  1. … 3 more files in changeset.
Extract type for holding module selectors

Instead of being a list, there is now an object that will be used to

perform some optimisations.

  1. … 3 more files in changeset.
Extract type for holding module selectors

Instead of being a list, there is now an object that will be used to

perform some optimisations.

  1. … 3 more files in changeset.
Extract type for holding module selectors

Instead of being a list, there is now an object that will be used to

perform some optimisations.

  1. … 3 more files in changeset.
Extract type for holding module selectors

Instead of being a list, there is now an object that will be used to

perform some optimisations.

  1. … 3 more files in changeset.
Add logging for dependency graph resolution

DO NOT MERGE INTO MASTER - THIS IS FOR TESTS ONLY

  1. … 9 more files in changeset.
Add verbose logging of dependency resolution

DO NOT MERGE INTO MASTER

  1. … 13 more files in changeset.