-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build: Rework shadow plugin configuration #32409
Conversation
Pinging @elastic/es-core-infra |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you Nik! This looks much cleaner. I have a couple questions.
benchmarks/build.gradle
Outdated
@@ -33,13 +33,13 @@ archivesBaseName = 'elasticsearch-benchmarks' | |||
test.enabled = false | |||
|
|||
dependencies { | |||
compile("org.elasticsearch:elasticsearch:${version}") { | |||
bundle("org.elasticsearch:elasticsearch:${version}") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we need to bundle anything in benchmarks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no clue. It has been shadowing all of its dependencies for ages and I was keeping it going. I could dig into it though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I didn't realize that. Quite odd, maybe @danielmitterdorfer can elaborate on why we do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an area where we can improve a lot: commenting the non-obvious choices in our code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's for convenience, so that you can run the benchmarks as simply as java -jar benchmarks.jar <class under benchmark>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done a little digging and I also think it is for convenience. Every example I see of using JMH shades the dependencies but this says that it is not required.
@@ -296,7 +297,7 @@ subprojects { | |||
// org.elasticsearch:elasticsearch must be the last one or all the links for the | |||
// other packages (e.g org.elasticsearch.client) will point to server rather than | |||
// their own artifacts. | |||
if (project.plugins.hasPlugin(BuildPlugin)) { | |||
if (project.plugins.hasPlugin(BuildPlugin) || project.plugins.hasPlugin(PluginBuildPlugin)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PluginBuildPlugin extends BuildPlugin, maybe it should apply it instead? Then we only need the one check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that'd be cleaner but I didn't want to do it while messing around with shadow stuff.
client/benchmark/build.gradle
Outdated
compile project(path: ':modules:reindex', configuration: 'runtime') | ||
compile project(path: ':modules:lang-mustache', configuration: 'runtime') | ||
compile project(path: ':modules:percolator', configuration: 'runtime') | ||
bundle("org.elasticsearch:elasticsearch:${version}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, why do benchmark jars for testing need bundled deps?
OK! I've removed the shadow stuff from benchmarks in another PR and rebased this on top. What do you think, @rjernst ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is much better, thanks! Just a couple final questions.
} | ||
} | ||
project.plugins.withType(ShadowPlugin).whenPluginAdded { | ||
project.afterEvaluate { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be done when the bundle configuration is added, in BuildPlugin, instead of in an afterEvaluate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BuildPlugin doesn't have isEclipse
or isIdea
but I can do this after the BuildPlugin is added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BuildPlugin doesn't have isEclipse or isIdea
Maybe it should? It seems odd to have to do this extra work, it should really be part of the base setup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll use it if it is defined.
@@ -39,6 +40,9 @@ public class JarHellTask extends LoggedExec { | |||
public JarHellTask() { | |||
project.afterEvaluate { | |||
FileCollection classpath = project.sourceSets.test.runtimeClasspath | |||
if (project.plugins.hasPlugin(ShadowPlugin)) { | |||
classpath += project.configurations.bundle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since compile
extends from bundle
, shouldn't this be in the test runtime classpath already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
compile
only extends from bundle
when we're configuring an IDE.
There are timing issues with moving the |
I ran into some issues with IntelliJ and had to do some minor fixups here. None of the build logic changed but a little of the configuration did. I'm retesting with @hub-cap to make sure this is good. It looks fine on my side but I don't know much about IntelliJ other than "open the project and click the hammer button". I'm also waiting on the PR testing robot to catch up with it. |
@nik9000 this looks good now from my end. Thank you for chasing down all the annoying bits here. <3 |
This reworks how we configure the `shadow` plugin in the build. The major change is that we no longer bundle dependencies in the `compile` configuration, instead we bundle dependencies in the new `bundle` configuration. This feels more right because it is a little more "opt in" rather than "opt out" and the name of the `bundle` configuration is a little more obvious. As an neat side effect of this, the `runtimeElements` configuration used when one project depends on another now contains exactly the dependencies needed to run the project so you no longer need to reference projects that use the shadow plugin like this: ``` testCompile project(path: ':client:rest-high-level', configuration: 'shadow') ``` You can instead use the much more normal: ``` testCompile "org.elasticsearch.client:elasticsearch-rest-high-level-client:${version}" ```
This change was made to master, this commit brings it over to index-lifecycle. See #32409
This change was made to master, this commit brings it over to index-lifecycle. See #32409
This reworks how we configure the
shadow
plugin in the build. The majorchange is that we no longer bundle dependencies in the
compile
configuration,instead we bundle dependencies in the new
bundle
configuration. This feelsmore right because it is a little more "opt in" rather than "opt out" and the
name of the
bundle
configuration is a little more obvious.As an neat side effect of this, the
runtimeElements
configuration used whenone project depends on another now contains exactly the dependencies needed
to run the project so you no longer need to reference projects that use the
shadow plugin like this:
You can instead use the much more normal: