Skip to content

Conversation

@pgomulka
Copy link
Contributor

@pgomulka pgomulka commented Sep 26, 2022

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

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
@pgomulka
Copy link
Contributor Author

a next step will be to generate named_components.json file where information about annotated plugin components which will be stored

@pgomulka pgomulka marked this pull request as ready for review September 26, 2022 14:06
@pgomulka pgomulka added >enhancement :Delivery/Build Build or test infrastructure labels Sep 26, 2022
@elasticsearchmachine elasticsearchmachine added the Team:Delivery Meta label for Delivery team label Sep 26, 2022
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-delivery (Team:Delivery)

@pgomulka pgomulka requested a review from breskeby September 27, 2022 15:02
Copy link
Contributor

@breskeby breskeby left a 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) { %>
Copy link
Contributor

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..
Copy link
Contributor

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"

implementationClass = 'org.elasticsearch.gradle.plugin.PluginBuildPlugin'
}
stableEsPlugin {
id = 'elasticsearch.stable_esplugin'
Copy link
Contributor

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> {
Copy link
Contributor

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();
Copy link
Contributor

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
}
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

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

@pgomulka pgomulka requested a review from breskeby October 3, 2022 14:30
* Map<String, byte[]> result = compile(sources);
* }</pre>
*/
public class InMemoryJavaCompiler {
Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor Author

@pgomulka pgomulka Oct 5, 2022

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?

Copy link
Contributor

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 {
Copy link
Contributor Author

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

@pgomulka pgomulka mentioned this pull request Oct 4, 2022
25 tasks
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));
Copy link
Contributor Author

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

Copy link
Contributor

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?
Copy link
Contributor Author

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?

Copy link
Contributor

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

@pgomulka
Copy link
Contributor Author

pgomulka commented Oct 5, 2022

@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));
Copy link
Contributor

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 @@
/*
Copy link
Contributor

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 @@
/*
Copy link
Contributor

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
}
Copy link
Contributor

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

@pgomulka
Copy link
Contributor Author

pgomulka commented Oct 5, 2022

@elasticmachine run elasticsearch-ci/bwc

1 similar comment
@pgomulka
Copy link
Contributor Author

pgomulka commented Oct 5, 2022

@elasticmachine run elasticsearch-ci/bwc

Copy link
Contributor

@breskeby breskeby left a 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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

"""
)
)
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

formatting seems off here

Copy link
Contributor Author

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)
Copy link
Contributor

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

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();
Copy link
Contributor

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

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

Copy link
Contributor

@breskeby breskeby left a 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


Copy link
Contributor

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?

Copy link
Contributor

@ChrisHegarty ChrisHegarty left a 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'
Copy link
Contributor

@ChrisHegarty ChrisHegarty Oct 6, 2022

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.

@pgomulka
Copy link
Contributor Author

pgomulka commented Oct 6, 2022

@elasticmachine run elasticsearch-ci/part-1

@pgomulka pgomulka merged commit d1f2b5d into elastic:main Oct 10, 2022
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 v8.6.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants