Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -2
    • +2
    ./resolver/DependenciesMetadataAdapterTest.groovy
  1. … 30 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).

    • -2
    • +2
    ./resolver/DependenciesMetadataAdapterTest.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).

    • -2
    • +2
    ./resolver/DependenciesMetadataAdapterTest.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).

    • -2
    • +2
    ./resolver/DependenciesMetadataAdapterTest.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).

    • -2
    • +2
    ./resolver/DependenciesMetadataAdapterTest.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).

    • -2
    • +2
    ./resolver/DependenciesMetadataAdapterTest.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).

    • -2
    • +2
    ./resolver/DependenciesMetadataAdapterTest.groovy
  1. … 77 more files in changeset.
Serialize dependency artifacts in for realized variant of metadata

Addition to #10372

    • -1
    • +2
    ./resolver/DependenciesMetadataAdapterOnGradleMetadataTest.groovy
  1. … 6 more files in changeset.
Serialize dependency artifacts in for realized variant of metadata

Addition to #10372

    • -1
    • +2
    ./resolver/DependenciesMetadataAdapterOnGradleMetadataTest.groovy
  1. … 6 more files in changeset.
Add test coverage for artifact selectors in GMM

    • -1
    • +1
    ./resolver/DependenciesMetadataAdapterOnGradleMetadataTest.groovy
  1. … 8 more files in changeset.
Fix failing tests from insecure HTTP deprecation changes

    • -19
    • +30
    ./DefaultMavenLocalRepositoryTest.groovy
  1. … 5 more files in changeset.
Fix failing tests from insecure HTTP deprecation changes

    • -1
    • +3
    ./DefaultIvyArtifactRepositoryTest.groovy
    • -1
    • +3
    ./DefaultMavenArtifactRepositoryTest.groovy
    • -2
    • +2
    ./transport/RepositoryTransportFactoryTest.groovy
  1. … 13 more files in changeset.
Fix DefaultFlatDirArtifactRepositoryTest

    • -1
    • +1
    ./DefaultFlatDirArtifactRepositoryTest.groovy
Merge branch 'master' into feature/JLL/depricate_http_download_dependencies

* master: (77 commits)

Realized component variants need to provide all attributes

Fix TeamCity Hygiene failures

New performance process (#10361)

Publish 5.6.1-20190825230025+0000

Publish 5.6.1-20190824230038+0000

Update .com userguide links

Update .com footer links

Update .com header links

Publish 5.6.1-20190823234015+0000

Rebase to latest 6.0 nightly

Revert "Recognize contributor"

Remove use of Java 11 API from instant execution

Recognize contributor

enhanced test source folder detection for eclipse task. (#10320)

Publish 5.6.1-20190823130927+0000

Rebase performance tests with 5.7-20190812122716+0000 baseline

Upgrade wrapper to 6.0 nightly

Rebase performance tests with 5.7-20190722220035+0000 baseline

Rebaseline to lock performance improvements

Temporarily use 5.6 as the baseline for Santa Tracker `assembleDebug` case.

...

    • -1
    • +3
    ./DefaultBaseRepositoryFactoryTest.groovy
    • -5
    • +5
    ./DefaultFlatDirArtifactRepositoryTest.groovy
  1. … 16 more files in changeset.
Refactor HTTP deprecation logic to use HttpRedirectVerifier

    • -2
    • +6
    ./DefaultBaseRepositoryFactoryTest.groovy
    • -1
    • +1
    ./DefaultMavenArtifactRepositoryTest.groovy
    • -9
    • +18
    ./transport/RepositoryTransportFactoryTest.groovy
  1. … 58 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -1
    • +3
    ./DefaultBaseRepositoryFactoryTest.groovy
    • -5
    • +5
    ./DefaultFlatDirArtifactRepositoryTest.groovy
  1. … 40 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -1
    • +3
    ./DefaultBaseRepositoryFactoryTest.groovy
    • -5
    • +5
    ./DefaultFlatDirArtifactRepositoryTest.groovy
  1. … 40 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -1
    • +3
    ./DefaultBaseRepositoryFactoryTest.groovy
    • -5
    • +5
    ./DefaultFlatDirArtifactRepositoryTest.groovy
  1. … 40 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -1
    • +3
    ./DefaultBaseRepositoryFactoryTest.groovy
    • -5
    • +5
    ./DefaultFlatDirArtifactRepositoryTest.groovy
  1. … 40 more files in changeset.
Only do maven artifact discovery for variants that require it

  1. … 10 more files in changeset.
Only do maven artifact discovery for variants that require it

  1. … 11 more files in changeset.
Only do maven artifact discovery for variants that require it

  1. … 10 more files in changeset.
Only do maven artifact discovery for variants that require it

  1. … 8 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

  1. … 14 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

  1. … 14 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

  1. … 14 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

  1. … 14 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

  1. … 14 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

  1. … 14 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

  1. … 14 more files in changeset.