95d56cc262
This fixes references to project that makes the plugin incompatible with Gradle configuration cache. We also remove custom xpackProject utility: using xpackProject in certain situations can break configure configuration cache compatibility as it uses a mutual project object under the hood that is discouraged to use in some use cases (e.g. at execution time) It always breaks compatibility with --configure-on-demand using xpackProject uses the project of the :x-pack project. referencing other project objects from other subproject should avoided where possible to decouple (sub project configurations). There's a good explanation of why we want to decouple our project configurations as much as possible here: https://docs.gradle.org/current/userguide/multi_project_configuration_and_execution.html#sec:decoupled_projects it adds little value over default out of the box gradle api (just use project(':x-pack:someProject') instead of xpackProject('someProject') Also in some occasions its even shorter. e.g. when this is used as xpackProject('someProject').path instead of just passing :x-pack:someProject I'll try to put a bit more context in the PR description in the future to make the motivation behind these kind of changes more clear upfront Related to #57918 |
||
|---|---|---|
| .. | ||
| src/test/java/org/elasticsearch | ||
| build.gradle | ||