Skip to content
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

Merged
merged 27 commits into from
Aug 22, 2018
Merged

Conversation

nik9000
Copy link
Member

@nik9000 nik9000 commented Jul 26, 2018

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}"

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

Copy link
Member

@rjernst rjernst left a 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.

@@ -33,13 +33,13 @@ archivesBaseName = 'elasticsearch-benchmarks'
test.enabled = false

dependencies {
compile("org.elasticsearch:elasticsearch:${version}") {
bundle("org.elasticsearch:elasticsearch:${version}") {
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member

@jasontedor jasontedor Jul 26, 2018

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>.

Copy link
Member Author

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)) {
Copy link
Member

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.

Copy link
Member Author

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.

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}")
Copy link
Member

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?

@nik9000
Copy link
Member Author

nik9000 commented Aug 1, 2018

OK! I've removed the shadow stuff from benchmarks in another PR and rebased this on top. What do you think, @rjernst ?

Copy link
Contributor

@alpar-t alpar-t left a 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!

Copy link
Member

@rjernst rjernst left a 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 {
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

@nik9000 nik9000 Aug 9, 2018

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.

@nik9000
Copy link
Member Author

nik9000 commented Aug 9, 2018

There are timing issues with moving the isIdea stuff to BuildPlugin. I think if we want to move isIdea and isEclipse to BuildPlugin we should move creating it to the plugin and we should do it in a separate change.

@nik9000
Copy link
Member Author

nik9000 commented Aug 21, 2018

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.

@hub-cap
Copy link
Contributor

hub-cap commented Aug 21, 2018

@nik9000 this looks good now from my end. Thank you for chasing down all the annoying bits here. <3

@nik9000 nik9000 merged commit 2c81d7f into elastic:master Aug 22, 2018
nik9000 added a commit that referenced this pull request Aug 22, 2018
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}"
```
gwbrown added a commit that referenced this pull request Aug 23, 2018
This change was made to master, this commit brings it over to
index-lifecycle.

See #32409
gwbrown added a commit that referenced this pull request Aug 29, 2018
This change was made to master, this commit brings it over to
index-lifecycle.

See #32409
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure >enhancement Team:Delivery Meta label for Delivery team v6.5.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants