Fix Gradle 4.3.1 compatibility for logging #27382
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ywelsch
added
:Delivery/Build
jasontedor
requested changes
Nov 15, 2017
| @@ -99,9 +101,11 @@ dependencies { | |||
|
|
|||
| // Gradle 2.14+ removed ProgressLogger(-Factory) classes from the public APIs | |||
| // Use logging dependency instead | |||
| // Gradle 4.3.1 stopped releasing the logging jars to jcenter, just use the last available one | |||
| GradleVersion logVersion = GradleVersion.current() > GradleVersion.version('4.3') ? GradleVersion.version('4.3') : GradleVersion.current() | |||
There was a problem hiding this comment.
I don’t think we should do this, I think we should depend on the right version. I understand that entails an additional external dependency, but the dependency will end up cached locally anyway except on Gradle upgrades. For CI this has no impact since we upgrade infrequently there.
There was a problem hiding this comment.
I think this is the wrong tradeoff. We use gradle-logging as a compileOnly dependency, and the interface we use has been super stable since forever. We would notice (build breaks) if something would change in that regard in future versions. Ignoring security concerns, adding a dependency on a repository that might not have the same uptime as jcenter could annoy us more... I've updated the PR according to your suggestion as I want to see this fixed.
There was a problem hiding this comment.
Okay, if this dependency is as stable as you say let's take it the way that you proposed first.
This reverts commit e21733a.
|
thansk @jasontedor |
ywelsch
added a commit
that referenced
this pull request
Nov 15, 2017
The build currently does not work with Gradle 4.3.1 as the Gradle team stopped publishing the gradle-logging dependency to jcenter, starting with 4.3.1 (not sure why). There are two options: - Add the repository managed by Gradle team (https://repo.gradle.org/gradle/libs-releases-local) to our build - Use an older version (4.3) of the dependency when running with Gradle 4.3.1. Not to depend on another external repo, I've chosen solution 2. Note that this solution could break on future versions, but as this is a compileOnly dependency, and the interface we use has been super stable since forever, I don't envision this to be an issue (and easily detected by a breaking build).
ywelsch
added a commit
that referenced
this pull request
Nov 15, 2017
The build currently does not work with Gradle 4.3.1 as the Gradle team stopped publishing the gradle-logging dependency to jcenter, starting with 4.3.1 (not sure why). There are two options: - Add the repository managed by Gradle team (https://repo.gradle.org/gradle/libs-releases-local) to our build - Use an older version (4.3) of the dependency when running with Gradle 4.3.1. Not to depend on another external repo, I've chosen solution 2. Note that this solution could break on future versions, but as this is a compileOnly dependency, and the interface we use has been super stable since forever, I don't envision this to be an issue (and easily detected by a breaking build).
ywelsch
added a commit
that referenced
this pull request
Nov 15, 2017
The build currently does not work with Gradle 4.3.1 as the Gradle team stopped publishing the gradle-logging dependency to jcenter, starting with 4.3.1 (not sure why). There are two options: - Add the repository managed by Gradle team (https://repo.gradle.org/gradle/libs-releases-local) to our build - Use an older version (4.3) of the dependency when running with Gradle 4.3.1. Not to depend on another external repo, I've chosen solution 2. Note that this solution could break on future versions, but as this is a compileOnly dependency, and the interface we use has been super stable since forever, I don't envision this to be an issue (and easily detected by a breaking build).
jasontedor
added a commit
that referenced
this pull request
Nov 16, 2017
* master: Stop skipping REST test after backport of #27056 Fix default value of ignore_unavailable for snapshot REST API (#27056) Add composite aggregator (#26800) Fix `ShardSplittingQuery` to respect nested documents. (#27398) [Docs] Restore section about multi-level parent/child relation in parent-join (#27392) Add TcpChannel to unify Transport implementations (#27132) Add note on plugin distributions in plugins folder Remove implementations of `TransportChannel` (#27388) Update Google SDK to version 1.23 (#27381) Fix Gradle 4.3.1 compatibility for logging (#27382) [Test] Change Elasticsearch startup timeout to 120s in packaging tests Docs/windows installer (#27369)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The build currently does not work with Gradle 4.3.1 as the Gradle team stopped publishing the gradle-logging dependency to jcenter, starting with 4.3.1 (not sure why). There are two options:
Not to depend on another external repo, I've chosen solution 2. Note that this solution could break on future versions, but as this is a compileOnly dependency, and the interface we use has been super stable since forever, I don't envision this to be an issue (and easily detected by a breaking build).