-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Create gradle plugin for ES stable plugins #90355
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
Conversation
New ES stable plugins when built should have a stable-plugin-descriptor.properties file instead of plugin-descriptor.properties. New plugins also do not use classname property in the plugin descriptor relates elastic#88980
|
a next step will be to generate named_components.json file where information about annotated plugin components which will be stored |
|
Pinging @elastic/es-delivery (Team:Delivery) |
breskeby
left a comment
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.
Hey there I left some comments we should address IMO. Also we should have that full StablePluginBuildPlugin functionality in this PR otherwise adding just the skeleton doesnt add any value IMO and each PR should have a purpose. Alternatively we just contain the refactoring here without the new Plugin
| # | ||
| # 'classname': the name of the class to load, fully-qualified. Only applies to | ||
| # "isolated" plugins | ||
| <% if (classname) { %> |
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.
We should put the if block around the description too IMO
| public GeneratePluginPropertiesTask(ProjectLayout projectLayout) { | ||
| setDescription("Generate " + PROPERTIES_FILENAME); | ||
| getOutputFile().convention(projectLayout.getBuildDirectory().file("generated-descriptor/" + PROPERTIES_FILENAME)); | ||
| // TODO I cannot tell if this is stable or not.. |
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.
To be honest I would just change it to a generic description like. "Generates Elasticsearch Plugin descriptor files"
build-tools/build.gradle
Outdated
| implementationClass = 'org.elasticsearch.gradle.plugin.PluginBuildPlugin' | ||
| } | ||
| stableEsPlugin { | ||
| id = 'elasticsearch.stable_esplugin' |
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.
our given convention is to use - instead of _ so it should be elasticsearch.stable-esplugin
| import org.gradle.api.file.RegularFile; | ||
| import org.gradle.api.provider.Provider; | ||
|
|
||
| public class StableBuildPlugin implements Plugin<Project> { |
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.
It should be StableBuildPluginPlugin really as we have also a Build Plugin and that would be confusing
| } | ||
|
|
||
| Map<String, String> getPluginProperties() { | ||
| Path propsFile = file("build/generated-descriptor/plugin-descriptor.properties").toPath(); |
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.
That seems not required anymore as we split the tests of Stable Plugin Build Plugin and and Build Plugin.
| file('module-consumer/build.gradle') << """ | ||
| configurations { | ||
| consume | ||
| } |
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.
In general the test that test functionality that moved into the BasePlugin should be moved into a BasePluginBuildPluginFunc test
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.
but I cannot really test basePluginBuildPlugin without applying 'elasticsearch.esplugin' or elasticsearch.stable-esplugin`.
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.
you can apply the BasePluginBuildPlugin just by using the classname
plugins.apply(org.elasticsearch.gradle.plugin. BasePluginBuildPlugin)
We do something similar to test internal plugins. see AbstractGradleInternalPluginFuncTest
| * Map<String, byte[]> result = compile(sources); | ||
| * }</pre> | ||
| */ | ||
| public class InMemoryJavaCompiler { |
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 we use anything from groovy to compile? maybe localclasses? bytebuddy?
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.
Not with the same convenience I guess as you can load groovy classes from a string, but you require writing it back to a jar as far as I understand?
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.
yes, I would have to get their byte code to write them to jar. Let's keep the InMemoryJavaCompiler here for now?
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.
👍
| import static java.nio.charset.StandardCharsets.UTF_8; | ||
| import static java.util.stream.Collectors.toUnmodifiableMap; | ||
|
|
||
| public final class JarUtils { |
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.
we can possibly avoid using this class if we use real test classes or localclasses
| t.setPluginClasses(mainSourceSet.getOutput().getClassesDirs()); | ||
| // it has to be compile classpath ?? otherwise libraries which are provided in runtime by es server won't be visible | ||
| // and we want to scan them too | ||
| t.setClasspath(project.getConfigurations().getByName(JavaPlugin.COMPILE_CLASSPATH_CONFIGURATION_NAME)); |
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.
it has to be compile classpath ?? otherwise libraries which are provided in runtime by es server won't be visible and we want to scan them too
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.
Usually a classpath property is the classpath required to run the GenerateNamedComponentsAction. I wonder if its needed at all. We probbaly can merge this with pluginClasses can't we?
| return jarFile; | ||
| } | ||
|
|
||
| //todo maybe we could refer to ../libs/plugin-api compile it and create a jar? |
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.
any views on this? is this possible?
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 don't see how this is possible. We run into a chicken egg problem here
|
@elasticmachine update branch |
| t.setPluginClasses(mainSourceSet.getOutput().getClassesDirs()); | ||
| // it has to be compile classpath ?? otherwise libraries which are provided in runtime by es server won't be visible | ||
| // and we want to scan them too | ||
| t.setClasspath(project.getConfigurations().getByName(JavaPlugin.COMPILE_CLASSPATH_CONFIGURATION_NAME)); |
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.
Usually a classpath property is the classpath required to run the GenerateNamedComponentsAction. I wonder if its needed at all. We probbaly can merge this with pluginClasses can't we?
| @@ -0,0 +1,14 @@ | |||
| /* | |||
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.
We really do not want java classes in src/(main test)/groovy as joint compilation is ridicolous slow. You can either just rename those classes to groovy or can you move them into testFixtures/java? Ultimately they are test fixtures aren't they?
| @@ -0,0 +1,14 @@ | |||
| /* | |||
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.
those should live in testFixtures/java and not in testFixtures/groovy
| file('module-consumer/build.gradle') << """ | ||
| configurations { | ||
| consume | ||
| } |
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.
you can apply the BasePluginBuildPlugin just by using the classname
plugins.apply(org.elasticsearch.gradle.plugin. BasePluginBuildPlugin)
We do something similar to test internal plugins. see AbstractGradleInternalPluginFuncTest
|
@elasticmachine run elasticsearch-ci/bwc |
1 similar comment
|
@elasticmachine run elasticsearch-ci/bwc |
breskeby
left a comment
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.
Some minor remarks.
| * Map<String, byte[]> result = compile(sources); | ||
| * }</pre> | ||
| */ | ||
| public class InMemoryJavaCompiler { |
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.
👍
| """ | ||
| ) | ||
| ) | ||
| ); |
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.
formatting seems off here
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.
it is intellijj's formatting. I will reformat manually. Side note - spotlessApply is not touching these files
| then: | ||
| result.task(":assemble").outcome == TaskOutcome.SUCCESS | ||
|
|
||
| println Files.readString(namedComponents) |
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.
guess this debug output can be removed
.../src/integTest/groovy/org/elasticsearch/gradle/plugin/StableBuildPluginPluginFuncTest.groovy
Show resolved
Hide resolved
| public abstract class GenerateNamedComponentsTask extends DefaultTask { | ||
| private static final Logger LOGGER = Logging.getLogger(GenerateNamedComponentsTask.class); | ||
| private static final String NAMED_COMPONENTS_FILE = "named_components.json"; | ||
| private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper(); |
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.
That OBJECT_MAPPER should live in the nested worker class IMO as its only used there
|
|
||
| def "can scan and create named components file"() { | ||
| given: | ||
| println testProjectDir.root |
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.
debug output can be removed
...ools/src/testFixtures/groovy/org/elasticsearch/gradle/fixtures/AbstractGradleFuncTest.groovy
Outdated
Show resolved
Hide resolved
breskeby
left a comment
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.
lgtm. Thank you!
|
|
||
| package org.elasticsearch.gradle.fixtures | ||
|
|
||
|
|
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 we revert this little import ordering change before merging?
ChrisHegarty
left a comment
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.
LGTM.
| implementationClass = 'org.elasticsearch.gradle.plugin.PluginBuildPlugin' | ||
| } | ||
| stableEsPlugin { | ||
| id = 'elasticsearch.stable-esplugin' |
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.
Let's go with this name for now, but reserve the right to change it.
|
@elasticmachine run elasticsearch-ci/part-1 |
New ES stable plugins when built should have a stable-plugin-descriptor.properties file instead of plugin-descriptor.properties.
New plugins also do not use classname property in the plugin descriptor
new plugin will also scan classes and libraries for @NamedComponents and will create named_components.json file. That file contains a map of Extensible interface (like TokenizerFactory) to a map of "component name" to "className"
This commit extracts common logic from PluginBuildPlugin into BasePluginBuildPLugin so that it can also be used by StableBuildPlugin
the differences are:
classaname - used in old plugin, but not in the new one (stable)
the plugin descriptor file name - the new one has stable-plugin-descriptor.properties
dependencies - the new plugin does not need elasticsearch as a dependency.
We might want to consider if we want to add test framework dependency in the future.
relates #88980