Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add sha-256 and sha-512 checksums to `maven-publish`

This commit adds the SHA-256 and SHA-512 checksums in:

- Gradle Module Metadata

- uploads to Maven repositories using the `maven-publish` plugin

The upload of those additional files is failsafe, just in case some

repositories don't support those checksum files.

  1. … 29 more files in changeset.
Add sha-256 and sha-512 checksums to `maven-publish`

This commit adds the SHA-256 and SHA-512 checksums in:

- Gradle Module Metadata

- uploads to Maven repositories using the `maven-publish` plugin

The upload of those additional files is failsafe, just in case some

repositories don't support those checksum files.

  1. … 29 more files in changeset.
Add sha-256 and sha-512 checksums to `maven-publish`

This commit adds the SHA-256 and SHA-512 checksums in:

- Gradle Module Metadata

- uploads to Maven repositories using the `maven-publish` plugin

The upload of those additional files is failsafe, just in case some

repositories don't support those checksum files.

  1. … 29 more files in changeset.
Add sha-256 and sha-512 checksums to `maven-publish`

This commit adds the SHA-256 and SHA-512 checksums in:

- Gradle Module Metadata

- uploads to Maven repositories using the `maven-publish` plugin

The upload of those additional files is failsafe, just in case some

repositories don't support those checksum files.

  1. … 29 more files in changeset.
Add sha-256 and sha-512 checksums to `maven-publish`

This commit adds the SHA-256 and SHA-512 checksums in:

- Gradle Module Metadata

- uploads to Maven repositories using the `maven-publish` plugin

The upload of those additional files is failsafe, just in case some

repositories don't support those checksum files.

  1. … 29 more files in changeset.
Backport test fixture improvements from 6.0 branch

  1. … 2 more files in changeset.
Backport test fixture improvements from 6.0 branch

  1. … 2 more files in changeset.
Backport test fixture improvements from 6.0 branch

  1. … 2 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Add more synchronization to http server fixture

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle

method behaved flaky.

Improve advice for dealing with insecure HTTP script plugins

  1. … 6 more files in changeset.
Add error message in case GMM doesn't declare variants

This commit validates that published Gradle Module Metadata

declares at least one variant when resolved. This is the

counterpart to validation at publication time, but this time

when resolving, in case a user/plugin generates module metadata

in a non-Gradle compatible way.

  1. … 6 more files in changeset.
Add error message in case GMM doesn't declare variants

This commit validates that published Gradle Module Metadata

declares at least one variant when resolved. This is the

counterpart to validation at publication time, but this time

when resolving, in case a user/plugin generates module metadata

in a non-Gradle compatible way.

  1. … 6 more files in changeset.
Extend test fixture for testing artifact selectors in GMM

  1. … 9 more files in changeset.
Module test fixture: add 'category' attribute to api/runtime variants

This reflects the default variant attributes of a published

java component.

  1. … 13 more files in changeset.
Module test fixture: add 'category' attribute to api/runtime variants

This reflects the default variant attributes of a published

java component.

  1. … 13 more files in changeset.
Do not drop variant attributes for 'traditional' maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

  1. … 27 more files in changeset.
Do not drop variant attributes for 'traditional' maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

  1. … 15 more files in changeset.
Add support for adding variants and files to component metadata rules

  1. … 32 more files in changeset.
Add support for adding variants and files to component metadata rules

  1. … 32 more files in changeset.
Add support for adding variants and files to component metadata rules

  1. … 31 more files in changeset.
Add support for adding variants and files to component metadata rules

  1. … 32 more files in changeset.
Add support for adding variants and files to component metadata rules

  1. … 32 more files in changeset.
Adjust tests and samples to new publishing default behavior

  1. … 43 more files in changeset.
wip - fix more tests

  1. … 46 more files in changeset.
wip - fix more tests

  1. … 45 more files in changeset.
wip - fix more tests

  1. … 46 more files in changeset.