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. … 33 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. … 33 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. … 33 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. … 33 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. … 33 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.
Update sshd to 2.0.0

The library has been split into multiple artifacts which need to added

as dependencies separately.

  1. … 2 more files in changeset.
Add support for resolving strict dependencies from an Ivy repository

So far strict dependencies were only supported when resolving from a Maven repository. This commit adds

the necessary infrastructure to make it work on Ivy repositories too. It's worth noting that similarly

to Maven, as soon as Gradle metadata is used, variants from the original Ivy metadata file are "ignored",

and it's a lossy conversion.

This commit is a "make it work". There's still missing test coverage, and there's redundant code due

to the replication of what has been setup for the Maven repositories. Subsequent commits will fix that.

  1. … 41 more files in changeset.
Make `MavenModule.rootMetaData` more consistent with other artifacts

- Can now use it consistently with other resource fixtures

- Use in GCS/S3/SFTP maven-publish tests for consistency

  1. … 9 more files in changeset.
Update tests for maven-publish with other repository transports

  1. … 5 more files in changeset.
Changed the Maven repository test fixtures to support publishing and resolving the Gradle module metadata.

  1. … 8 more files in changeset.
Move GFileUtils to base-services

+review REVIEW-6562

  1. … 30 more files in changeset.
Change repository test fixtures to allow the repository path and backing file of artifacts to be queried by test.

  1. … 16 more files in changeset.
Switch to from DSA to RSA in our integration testing SFTP server

This may solve the `SignatureException: Invalid encoding for signature`

issue we see when running this on newer Java8 versions.

Switch to from DSA to RSA in our integration testing SFTP server

This may solve the `SignatureException: Invalid encoding for signature`

issue we see when running this on newer Java8 versions.

Upgrade sshd dependency to 1.2.0 (used in integration tests)

This might solve the flakiness issues we currently see with

the `SFTPServer` test fixture. sshd 1.2.0 works with Java7, while

1.2.0+ versions require Java8.

  1. … 1 more file in changeset.
Change test to simply close connections rather than restarting sftp server

  1. … 1 more file in changeset.
Check that an existing sftp connection is still connected before reuse

  1. … 4 more files in changeset.
Added some int test coverage for interaction between Maven scopes and Ivy configurations.

  1. … 25 more files in changeset.
Ease creation of plugin modules for maven and ivy

  1. … 5 more files in changeset.
Changing Play and SFTP integration tests to dynamically assign ports at bind time.

+review REVIEW-5579

  1. … 15 more files in changeset.
Refactoring port allocation to use fixed ranges based on test workers

+review REVIEW-5579

  1. … 22 more files in changeset.
Reverting SftpServer to AvailablePortFinder until issue can be resolved

Forcing sshd to always wait for stop in an attempt to address apparent test flakiness

+review REVIEW-5579

First stab at a multicast port allocator test fixture

+review REVIEW-5579

  1. … 28 more files in changeset.
Extracted a basic int test that verifies 'uploadArchives' for each transport, from various existing tests.

  1. … 14 more files in changeset.
Replaced RemoteIvyRepository.expectDirectoryList() with directoryList() that returns a RemoteResource, added SftpDirectoryResource

    • -0
    • +65
    ./SftpDirectoryResource.groovy
  1. … 11 more files in changeset.