Create gradle plugin for ES stable plugins#90355
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.
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.
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.
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.
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.
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.
That seems not required anymore as we split the tests of Stable Plugin Build Plugin and and Build Plugin.
| @@ -75,7 +75,7 @@ class PluginBuildPluginFuncTest extends AbstractGradleFuncTest { | |||
| } | |||
There was a problem hiding this comment.
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.
but I cannot really test basePluginBuildPlugin without applying 'elasticsearch.esplugin' or elasticsearch.stable-esplugin`.
There was a problem hiding this comment.
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.
can we use anything from groovy to compile? maybe localclasses? bytebuddy?
There was a problem hiding this comment.
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.
yes, I would have to get their byte code to write them to jar. Let's keep the InMemoryJavaCompiler here for now?
| 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.
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.
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.
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.
any views on this? is this possible?
There was a problem hiding this comment.
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.
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.
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.
those should live in testFixtures/java and not in testFixtures/groovy
| @@ -75,7 +75,7 @@ class PluginBuildPluginFuncTest extends AbstractGradleFuncTest { | |||
| } | |||
There was a problem hiding this comment.
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 |
| * Map<String, byte[]> result = compile(sources); | ||
| * }</pre> | ||
| */ | ||
| public class InMemoryJavaCompiler { |
| """ | ||
| ) | ||
| ) | ||
| ); |
There was a problem hiding this comment.
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.
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.
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.
debug output can be removed
...ools/src/testFixtures/groovy/org/elasticsearch/gradle/fixtures/AbstractGradleFuncTest.groovy
Outdated
Show resolved
Hide resolved
|
|
||
| package org.elasticsearch.gradle.fixtures | ||
|
|
||
|
|
There was a problem hiding this comment.
can we revert this little import ordering change before merging?
| implementationClass = 'org.elasticsearch.gradle.plugin.PluginBuildPlugin' | ||
| } | ||
| stableEsPlugin { | ||
| id = 'elasticsearch.stable-esplugin' |
There was a problem hiding this comment.
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