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

feat: gradle build to support Elasticsearch 8.x #6

Merged
merged 2 commits into from
Jan 13, 2023

Conversation

ssaarinen
Copy link

ES8 requires Java 17 and plugin SPI has minor change compared to 7.x which makes it backwards incompatible.

ES8 support in the build works by defining new source set for ES8 that contains the only incompatible class (RaudikkoTokenFilterFactory) that gets it's own ES8 classpath during development.

When running the build against 8.x target java toolchain is switched to 17 and the main source set is configured to include the 8.x compatible FilterFactory and to exclude the 7.x version.

Docker compose added for easier verification that the plugin works.

resolves: #5

Copy link
Member

@komu komu left a comment

Choose a reason for hiding this comment

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

Hi, thanks for the PR! Good work.

As a general note, when submitting PRs to Raudikko (and I believe most other projects), please try to build a logical set of commits on top of each other, instead of bundling all your changes into a single commit. Sometimes it's even a good idea to open several PRs in order to get the uncontroversial foundation merged before the actual changes that you're targeting.

So in this case the Gradle version update has nothing to do with the rest of the changes and while it's probably overkill to open a separate PR for that, having it as a separate commit on bottom of other changes sounds like a good idea.

Similarly the "build with Docker"-stuff is unrelated to the rest of the changes and whether we'll want to merge or not is orthogonal to other issues here. No need to have it in this PR, just open a separate one and explain there what problem it solves and we can take a look at it separately.

Furthermore, I'm a bit concerned that now there's logical duplication. If we'd like to add a new flag, we'd have to remember to update two places. One solution would be to have both filters delegate their work to a shared class. But truthfully, that feels like overkill in this case. Then again, I would feel compelled to at least leave comments on both ends of the duplication, mentioning that you need to update the other end as well. (Not that anyone reads those, but hey, we tried our best.)

Now, as for the actual solution, a few weeks ago we discussed with @hakuzumon whether we want to support old versions and have separate source sets or if we'd rather just drop support for the old versions and then make releases for them from a maintenance branch, if that is ever needed. We decided for the second option. No need to complicate the build as we probably rarely need to make builds for old versions.

So I won't merge this as it is, but this feels like fine work, so if you submit the same thing simplified so that there's no multiple source sets, no support for old versions and no extra things, I will.

Thanks again, great to have support for 8.x!

Samuli Saarinen added 2 commits December 31, 2022 17:28
Tried to use 7.6 and it works but Idea gives some errors on build file.
@@ -34,7 +34,7 @@ val distributionZip = tasks.register<Zip>("distributionZip") {
from(file("src/main/plugin-metadata")) {
expand(
"pluginVersion" to project.version,
"javaVersion" to System.getProperty("java.specification.version"),
Copy link
Author

Choose a reason for hiding this comment

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

I don't know if this has any impact but now it follows the toolchain java version and not the version running gradle

@ssaarinen
Copy link
Author

Agree with you 100%. Makes it far simpler to just drop the 7.x support.

@ssaarinen
Copy link
Author

btw. what comes to unrelated changes I would consider adding most (maybe all) of .idea to .gitignore. Seems like changes there are related to my environment and tracking those is really annoying :/

@komu
Copy link
Member

komu commented Jan 13, 2023

btw. what comes to unrelated changes I would consider adding most (maybe all) of .idea to .gitignore. Seems like changes there are related to my environment and tracking those is really annoying :/

Yeah, I think I'll do that. It's really annoying that whenever JetBrains manages to fix some of the environment related things, others will creep in. In theory, most of the .idea should be checked in, but in practice it can't.

@komu komu merged commit 003d1a4 into EvidentSolutions:master Jan 13, 2023
@komu
Copy link
Member

komu commented Jan 13, 2023

Thanks again and sorry for the delay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Request - Any plans for Elasticsearch 8.4 support?
2 participants