[Build] Rework internal build plugin plugin to work with Isolated Projects#123461
[Build] Rework internal build plugin plugin to work with Isolated Projects#123461breskeby merged 6 commits intoelastic:mainfrom
Conversation
c79bac8 to
ca0117d
Compare
ed1832e to
9759f49
Compare
|
Pinging @elastic/es-delivery (Team:Delivery) |
modules/aggregations/build.gradle
Outdated
| classname ='org.elasticsearch.aggregations.AggregationsPlugin' | ||
| extendedPlugins = ['lang-painless'] | ||
| extendedPluginProjects { | ||
| "lang-painless" { |
There was a problem hiding this comment.
This syntax seems a bit verbose. Is there a way we could use just the project path, and resolve something from the project at runtime to determine the plugin name? Most of the time this is just the project name, so having to specify it twice along with the extra syntax feels like unnecessary boilerplate.
There was a problem hiding this comment.
The problem is that unfortunately the naming is not deterministic across the different plugins. At the moment the actual name is declared in the build script only. We could resolve the name maybe by resolving the generated plugin properties, but for now I prefer this little bit boilerplate in the definition over the constant cost of trying to be clever here and resolve that dynamically.
Looking at this again, I just realize we might have a better way to move forward here as we only need the the project path atm to configure a potential test cluster automatically. Given we use less and less the test cluster plugin we probably tweak this to not generally change the plugin declaration but just do the module dependency in the test clusters explicitly.
puh, let me revisit this again 🤡
There was a problem hiding this comment.
@rjernst turns out alls this was basically not required in our current codebase. see https://github.com/elastic/elasticsearch/pull/123461/files#r1995753719
- Update restrited buildservice
484b12a to
dfe7d45
Compare
| if (isModule == false || isXPackModule) { | ||
| addNoticeGeneration(project, extension); | ||
| } | ||
| project.afterEvaluate(p -> { |
There was a problem hiding this comment.
Actually this was only used by internal plugins that
a) still rely on test cluster plugin,
b) extend other plugins
c) do not use default distribution
which is actually ZERO
c3ab3e4 to
ce2aef6
Compare
rjernst
left a comment
There was a problem hiding this comment.
LGTM. FWIW it would be nice to not have to specify dependencies twice, once in the plugin properties block, and again under dependencies. But this is good on its own.
true. we would need some stronger modelling here for this. |
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
* main: (95 commits) Mute org.elasticsearch.datastreams.lifecycle.DataStreamLifecycleServiceIT testLifecycleAppliedToFailureStore elastic#124999 Merge template mappings properly during validation (elastic#124784) [Build] Rework internal build plugin plugin to work with Isolated Projects (elastic#123461) [Build] Require reason for usesDefaultDistribution (elastic#124707) Mute org.elasticsearch.packaging.test.DockerTests test011SecurityEnabledStatus elastic#124990 Mute org.elasticsearch.xpack.ilm.TimeSeriesDataStreamsIT testRolloverAction elastic#124987 Mute org.elasticsearch.packaging.test.BootstrapCheckTests test10Install elastic#124957 Mute org.elasticsearch.integration.DataStreamLifecycleServiceRuntimeSecurityIT testRolloverLifecycleAndForceMergeAuthorized elastic#124978 Mute org.elasticsearch.xpack.esql.action.CrossClusterAsyncQueryStopIT testStopQuery elastic#124977 Mute org.elasticsearch.xpack.esql.action.CrossClusterAsyncQueryStopIT testStopQueryLocal elastic#121672 Mention zero-window state in networking docs (elastic#124967) Remove remoteAddress field from TransportResponse (elastic#120016) Include failures in partial response (elastic#124929) Prevent work starvation bug if using scaling EsThreadPoolExecutor with core pool size = 0 (elastic#124732) Re-enable analysis stemmer test (elastic#124961) Mute org.elasticsearch.xpack.esql.action.CrossClusterAsyncQueryStopIT testStopQueryLocalNoRemotes elastic#124959 ESQL: Catch parsing exception (elastic#124958) ESQL: Improve error message for ( and [ (elastic#124177) Mute org.elasticsearch.xpack.esql.qa.single_node.EsqlSpecIT test {lookup-join.MvJoinKeyFromRow SYNC} elastic#124951 Mute org.elasticsearch.datastreams.lifecycle.DataStreamLifecycleServiceIT testErrorRecordingOnRetention elastic#124950 ... # Conflicts: # server/src/main/java/org/elasticsearch/index/mapper/vectors/DenseVectorFieldMapper.java # server/src/test/java/org/elasticsearch/index/mapper/vectors/DenseVectorFieldTypeTests.java
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
This fixes a general flaw in our build logic where we reach out to configurations of other projects.
This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration
of subprojects.