Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

  1. … 7 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

  1. … 4 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

  1. … 9 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

  1. … 9 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

  1. … 9 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

  1. … 9 more files in changeset.
Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

  1. … 4 more files in changeset.
Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

  1. … 4 more files in changeset.
Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

  1. … 4 more files in changeset.
Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

  1. … 4 more files in changeset.
Use the dependency artifacts of all selectors for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we also need to consider all

this information early when we look for an artifact (instead of a

metadata file).

  1. … 9 more files in changeset.
Collect all dependency artifacts in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where er search for modules

in repositories.

  1. … 4 more files in changeset.
Deprecated `force` on first-level dependencies

This commit deprecates using `force` in favor of using the

new "strictly" behavior. The "force" flag is still used

internally, in particular in case of virtual platforms, but

its usage should be discouraged as we have a solution which

is better now.

  1. … 23 more files in changeset.
Deprecated `force` on first-level dependencies

This commit deprecates using `force` in favor of using the

new "strictly" behavior. The "force" flag is still used

internally, in particular in case of virtual platforms, but

its usage should be discouraged as we have a solution which

is better now.

  1. … 18 more files in changeset.
Deprecated `force` on first-level dependencies

This commit deprecates using `force` in favor of using the

new "strictly" behavior. The "force" flag is still used

internally, in particular in case of virtual platforms, but

its usage should be discouraged as we have a solution which

is better now.

  1. … 23 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. … 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.
Apply `Explicit type can be replaced with <>` inspection the whole project

  1. … 909 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 901 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 889 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 896 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 901 more files in changeset.