Remove guava from transitive compile classpath#54309
Merged
rjernst merged 16 commits intoelastic:masterfrom Apr 2, 2020
Merged
Remove guava from transitive compile classpath#54309rjernst merged 16 commits intoelastic:masterfrom
rjernst merged 16 commits intoelastic:masterfrom
Conversation
Guava was removed from Elasticsearch many years ago, but remnants of it remain due to transitive dependencies. When a dependency pulls guava into the compile classpath, devs can inadvertently begin using methods from guava without realizing it. This commit moves guava to a runtime dependency in the modules that it is needed. Note that one special case is the html sanitizer in watcher. The third party dep uses guava in the PolicyFactory class signature. However, only calling a method on the PolicyFactory actually causes the class to be loaded, a reference alone does not trigger compilation to look at the class implementation. There we utilize a MethodHandle for invoking the relevant method at runtime, where guava will continue to exist.
Collaborator
|
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
Contributor
And people thought Gradle was being dumb by introducing |
mark-vieira
approved these changes
Mar 26, 2020
Contributor
mark-vieira
left a comment
There was a problem hiding this comment.
Couple comments, otherwise LGTM.
| configuration.resolutionStrategy.eachDependency { | ||
| String artifactName = it.target.name | ||
| if (FORBIDDEN_DEPENDENCIES.contains(artifactName)) { | ||
| throw new GradleException("Dependency '${artifactName}' on configuration '${configuration.name}' is not allowed. " + |
Contributor
There was a problem hiding this comment.
We might want to include the full path to the configuration here as just saying "compileClasspath" isn't going to be particularly helpful.
Member
Author
There was a problem hiding this comment.
This is the current failure output. It has the full path in the first part of the error.
> Could not resolve all files for configuration ':x-pack:plugin:identity-provider:compileClasspath'.
> Could not resolve com.google.guava:guava:19.0.
Required by:
project :x-pack:plugin:identity-provider
> Dependency 'guava' on configuration 'compileClasspath' is not allowed. If it is needed as a transitive depenency, try adding it to the runtime classpath
| } | ||
|
|
||
| subprojects { | ||
| pluginManager.withPlugin('java') { |
Contributor
There was a problem hiding this comment.
It's worth nothing that standalone QA projects do no apply the java plugin but only java-base.
Member
Author
There was a problem hiding this comment.
I appreciate that, but still think this is a good start.
Member
|
This pull request is a thing of beauty to bury the zombie that tried to come back. |
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
Apr 2, 2020
Guava was removed from Elasticsearch many years ago, but remnants of it remain due to transitive dependencies. When a dependency pulls guava into the compile classpath, devs can inadvertently begin using methods from guava without realizing it. This commit moves guava to a runtime dependency in the modules that it is needed. Note that one special case is the html sanitizer in watcher. The third party dep uses guava in the PolicyFactory class signature. However, only calling a method on the PolicyFactory actually causes the class to be loaded, a reference alone does not trigger compilation to look at the class implementation. There we utilize a MethodHandle for invoking the relevant method at runtime, where guava will continue to exist.
rjernst
added a commit
that referenced
this pull request
Apr 8, 2020
Guava was removed from Elasticsearch many years ago, but remnants of it remain due to transitive dependencies. When a dependency pulls guava into the compile classpath, devs can inadvertently begin using methods from guava without realizing it. This commit moves guava to a runtime dependency in the modules that it is needed. Note that one special case is the html sanitizer in watcher. The third party dep uses guava in the PolicyFactory class signature. However, only calling a method on the PolicyFactory actually causes the class to be loaded, a reference alone does not trigger compilation to look at the class implementation. There we utilize a MethodHandle for invoking the relevant method at runtime, where guava will continue to exist.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Guava was removed from Elasticsearch many years ago, but remnants of it
remain due to transitive dependencies. When a dependency pulls guava
into the compile classpath, devs can inadvertently begin using methods
from guava without realizing it. This commit moves guava to a runtime
dependency in the modules that it is needed.
Note that one special case is the html sanitizer in watcher. The third
party dep uses guava in the PolicyFactory class signature. However, only
calling a method on the PolicyFactory actually causes the class to be
loaded, a reference alone does not trigger compilation to look at the
class implementation. There we utilize a MethodHandle for invoking the
relevant method at runtime, where guava will continue to exist.
Additionally, this commit adds a build time check that we do not add any compile dependency on guava.