Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

  1. … 12 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

  1. … 12 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

  1. … 12 more files in changeset.
Merge resources integration tests

  1. … 109 more files in changeset.
Adjust tests and samples to new metadata sources defaults

  1. … 94 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.
Adjust tests and samples to new metadata sources defaults

  1. … 15 more files in changeset.
Adjust tests and samples to new metadata sources defaults

  1. … 15 more files in changeset.
Adjust tests and samples to new metadata sources defaults

  1. … 15 more files in changeset.
Adjust tests following Gradle Module Metadata feature preview removal

  1. … 29 more files in changeset.
Adjust tests following Gradle Module Metadata feature preview removal

  1. … 29 more files in changeset.
Adjust tests following Gradle Module Metadata feature preview removal

  1. … 29 more files in changeset.
Apply `Standard Charset object can be used` inspection the whole project

  1. … 10 more files in changeset.
Apply `Anonymous type can be replaced with lambda` inspection the whole project

  1. … 665 more files in changeset.
Apply `'try finally' replaceable with 'try' with resources` inspection the whole project

  1. … 53 more files in changeset.
Apply `Explicit type can be replaced with <>` inspection the whole project

  1. … 909 more files in changeset.
Upgrade commons-lang{->3} replacing packages

  1. … 175 more files in changeset.
Organize imports

  1. … 339 more files in changeset.
Replace anonymous classes with lambdas

  1. … 710 more files in changeset.
Replace anonymous classes with lambdas

  1. … 694 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.