Skip to content
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

Convert PluginPropertiesExtension Groovy to Java #39605

Merged
merged 14 commits into from
Jun 13, 2019

Conversation

rhamedy
Copy link
Contributor

@rhamedy rhamedy commented Mar 2, 2019

Contributes to #34459

Converted

  • PluginPropertiesExtension.groovy -> java
  • Deleted the groovy files

@rhamedy
Copy link
Contributor Author

rhamedy commented Mar 4, 2019

Tried to convert the BuildPluginBuild.groovy to java and include it in this PR however, I hit a few roadblocks relating to

  • Replacing project.pluginProperties.extension.name equivalentwith project.getTasks().getByName("pluginProperties").getName()?
  • How to access module in project.integTestCluster.module(project)?
  • No publishing property on project for project.publishing.publications.nebula(MavenPublication).artifactId
  • A few others like this

I have paused working on BuildPluginBuild.groovy because of one too many question marks. Not sure if this PR can go through independent of BuildPluginBuild refactor?

@colings86 colings86 added the :Delivery/Build Build or test infrastructure label Mar 4, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

Copy link
Contributor

@alpar-t alpar-t left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution @rhamedy !
We prefer small PRs so this is even better than having the plugin converted too.
I left a few comments. Also would be kind enough and add tests for these classes ?
We want all the java code to have tests.

@rhamedy
Copy link
Contributor Author

rhamedy commented Mar 8, 2019

@atorok thank you for the review. I have addressed them in my recent commit as well as replied to some of your comments that need a reply.

I would definitely write tests! Is there a test class that I could use as a guide? I need a little sense of direction on how write tests 🙂

@alpar-t
Copy link
Contributor

alpar-t commented Mar 8, 2019

Thanks @rhamedy for the quick update. For tests I think you should look at GradleUnitTestCase and other classes that implement it.

@elasticmachine test this please

@rhamedy
Copy link
Contributor Author

rhamedy commented Mar 12, 2019

@atorok I have addressed the code review comments as well as added some tests. I could not find a class that I could use as baseline to write tests probably because the tests are different in other classes and this is plugin.

The test ensures tha the plugin-descriptor.properties file is picked up from classpath and it's substituted with props from extension and it's saved in the project build directory under templates.

Please let me know if any changes to be made 👍

@alpar-t
Copy link
Contributor

alpar-t commented Mar 12, 2019

@elasticmachine test this please

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

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

Thanks for taking this on @rhamedy. I left a few comments.

@rhamedy
Copy link
Contributor Author

rhamedy commented Mar 12, 2019

@rjernst and @atorok thank you for the review. Replied to the comments. Do you have any feedback on unit tests? It would be nice to tackle the review changes along with tests all at once.

@rhamedy
Copy link
Contributor Author

rhamedy commented Mar 14, 2019

@rjernst @atorok I pushed up my new changes taking into account the code review comments. I have removed the unecessary test/resources/plugin-descriptor.properties file and after throwing away the doLast everything works magically and according to my tests the templates and generated-resources directories have correct content 👍


public PluginPropertiesExtension(Project project) {
this.name = project.getName();
this.version = project.getVersion().toString();
Copy link
Contributor

Choose a reason for hiding this comment

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

I just realized this now, this is a problem present in the old code as well.
The way we assign this default makes it prone to ordering.
If the extension is created before project.version is assigned we won't pick it up.
We should have a null check in the getter instead and returnproject.version if version is null
This is fine also in a subsequent PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can update the PluginPropertiesExtension.getVersion() to return project.getVersion().toString() if version is null 👍

Copy link
Member

Choose a reason for hiding this comment

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

It is not possible for version to be null. VersionProperties statically loads the version. BuildPlugin is initialized before any PluginPropertiesExtension, since it is applied by PluginBuildPlugin, which extends BuildPlugin. Adding null checks all over for version will only make the code more complicated to understand with no actual additional safety.

Copy link
Contributor

Choose a reason for hiding this comment

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

We do this early on in the root level build.gradle

allprojects {
  group = 'org.elasticsearch'
  version = VersionProperties.elasticsearch
  description = "Elasticsearch subproject ${project.path}"
}

So indeed it's not possible for project.version to be null in our build,
but all bets are off for external plugins, there's no guarantee that it won't be null.
We might not want to be lenient here and throw an exception if the version is null, but I still think we should do it rather than leave it be an NPE.
Alternatively, we could hard code this to VersionProperties.elasticsearch as we only test building plugins where the version of build-tools matches that of elasticsearch.
External plugins can then have whatever project.version they like.
What do you think of this approach @rjernst

@alpar-t
Copy link
Contributor

alpar-t commented Mar 19, 2019

@elasticmachine test this please

@rhamedy
Copy link
Contributor Author

rhamedy commented Mar 22, 2019

@atorok @rjernst I have factored the changes requested and pushed the changes up. The tests that I have added are working 👍 however when running the command ./gradlw check I get the following error

> Task :modules:aggs-matrix-stats:pluginProperties FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':modules:aggs-matrix-stats:pluginProperties'.
> java.nio.file.FileAlreadyExistsException: /Users/raf/workspace/opensource-contributions/elastic/elasticsearch/modules/aggs-matrix-stats/build/templates/plugin-descriptor.properties

I double checked the modules:aggs-matrix-stats and unlike the exception the file modules/aggs-matrix-stats/build/templates/plugin-descriptor.properties is `present 🤔

@alpar-t
Copy link
Contributor

alpar-t commented Mar 22, 2019

@elasticmachine test this please

@rhamedy
Copy link
Contributor Author

rhamedy commented Mar 23, 2019

@atorok @rjernst please let me know if any further changes need to be made. I will clean up (squash) the commits after the PR is in mergeable state 🙂

Copy link
Contributor

@alpar-t alpar-t left a comment

Choose a reason for hiding this comment

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

LGTM no need to squash we do that on merge anyhow.

@rjernst
Copy link
Member

rjernst commented Mar 28, 2019

@elasticmachine test this please

@rhamedy rhamedy force-pushed the plugin-properties-task-tojava branch from 758a406 to 03fa92f Compare April 17, 2019 05:07
@alpar-t
Copy link
Contributor

alpar-t commented Apr 17, 2019

@elasticmachine test this please

@rhamedy
Copy link
Contributor Author

rhamedy commented Apr 17, 2019

@atorok pushed my changes! 👍

@alpar-t
Copy link
Contributor

alpar-t commented Apr 17, 2019

@elasticmachine test this please

@alpar-t
Copy link
Contributor

alpar-t commented Apr 18, 2019

@rhamedy looks like there are some failing tests

@rhamedy
Copy link
Contributor Author

rhamedy commented Apr 20, 2019

@atorok the recent changes fix the test failures 👍

@rhamedy rhamedy changed the title Convert PluginPropertiesExtension & PluginPropertiesTask Groovy to Java Convert PluginPropertiesExtension Groovy to Java Apr 20, 2019
@alpar-t
Copy link
Contributor

alpar-t commented Apr 23, 2019

@elasticmachine test this please

@alpar-t
Copy link
Contributor

alpar-t commented Jun 12, 2019

Sorry for the delay @rhamedy I'll see to merge this as soon as the PR checks pass

Merge remote-tracking branch 'origin/master' into plugin-properties-task-tojava
When the version is not set, use the project version bu do so lazily so
we don't snapshot it at construction time
@rhamedy
Copy link
Contributor Author

rhamedy commented Jun 13, 2019

@atorok that would be awesome! 🙂

@alpar-t alpar-t merged commit 04df52a into elastic:master Jun 13, 2019
@rhamedy rhamedy deleted the plugin-properties-task-tojava branch October 7, 2019 01:17
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
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 >non-issue Team:Delivery Meta label for Delivery team v7.2.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants