What about RequestContext class? It’s outside od wireing package but it is ES dependent class. First of all we should have to identify all classes which contain ror Logic and ES dependent code. Then we could define interfaces for ROR parts and provide different implementations for all supported ES versions. Obviously for every ES code we should create gradle module. And yes … modules seem to behave like packages, but there is one difference. For each module we could define separate gradle.build file and define ES plugin version. Then it will be possible to build plugin for all supported versions or for chosen version. I’ve only checked 5.3.x and 5.2.x versions and it seems to be doable. Maybe for Old versions it would be more difficult
Yes, the idea of “wiring” package was good, but stuff went untidy (my fault) and now references to Elasticsearch internals are all over the place again. I.e. I need to come up with a ResponseContext too (see the littering of “instanceof” in indices rewrite rule onResponse hook).
I reallyI like your idea of having every version in the same branch at the same time (one ES version == one gradle module).
If I’m understanding this right, we’d have a few advantages:
- When we break the wiring contract, one or more modules break and we fix it on the spot.
- Integration tests can be run across versions and CI won’t pass until every version works.
- If CI satisfies all supported versions, we can release nightly builds for all versions and speed up dev a LOT.
Do you think we can manage to explain to Gradle it has to run the same docker tests against 5.3, 5.2, and so on? 
As I said, I don’t know gradle well … and AFAIK elasticsearch plugin requires to use gradle 2 (2.3?).
But I know that I could do this with sbt, so I assume gradle also allows to do it.
As the last resort we could create simple bash script to run ./gradlew test for each ES-module.
Yeah I agree on both points, if bash does the job, welcome bash (and generally it does, and the result is portable).
And I too largely prefer SBT. We ended up in gradle because at the time of porting the code to 5.x (it was super hard) I only found examples in gradle which included gradle-specific ES tooling extensions. So I though it was the only way to build a functioning deliverable. Most likely this is not true.
Another exciting perspective would be to eventually have the generic RR module in Scala (once the Java API wiring is all taken care of and we can reason in terms of simple POJO/case classes).
But let’s do one step at a time. Now I’ll take care of isolating the ES-dependant code inside wiring package first!
If you want I can try to create some prototype of the described solution. It is some sort of challenge, so I can spend a few days on it (but on the other hand I know in advance that I will curse the Gradle).
1 Like
Yeah I think in the medium-long run this will greatly pay off. Divide & conquer + leveling up automation = Totally worth it!
Meanwhile I’m going to stabilise the new code and tidy up the current wiring vs generic packages.
Thanks @coutoPL!
great. I’m going to start today. We’ll see what comes out.
1 Like