NMS-13134: Support ES 7.10.2 and change project structure

[swachter]

• Each supported ES version is now represented by a module of its own (instead of a branch)
• Versions are released by tagging commits in master
• Tags must have the form v<version>_<es_modules> where <es_modules> is a comma separated list of the module names
• Maven's revision mechanism is used to set versions
• Debian and RPM packages are built by fpm
• The version scheme is 1:<version>-1 for releases and 1:<version>~SNAPSHOT-<timestamp> for snapshots; this ensures that releases are newer than their previous snapshots
• deploys packages to cloudsmith

https://issues.opennms.org/browse/NMS-13134

PS: We may decide to remove the epoch 1: prefix from versions.

[j-white]

I'm curious about the updated project structure, how do we see the modules evolving over time?

I guess it will look like this plugin that does something similar: https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin

I had initially modelled the branch structure/tagging after this one: https://github.com/ForgeRock/es-change-feed-plugin

[swachter]

I'm curious about the updated project structure, how do we see the modules evolving over time?

I guess it will look like this plugin that does something similar: https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin

We will add another module each time we plan to support a new ES version and we will delete a module if we do not intend to publish new versions of the plugin for the corresponding ES version. Therefore the number of modules will not steadily increase.

In case of a new plugin version (e.g. adding a new feature to the plugin) the changes have to be applied to all modules. Admittedly this is a drawback. However, we may add a "shared" module in future that is ES independent and that may contain shared code. The shared module may also contain test sources that can be used in the tests of ES specific modules.

I had initially modelled the branch structure/tagging after this one: https://github.com/ForgeRock/es-change-feed-plugin

IMO having modules instead of branches is easier to manage (at least for a restricted number of modules).

[indigo423]

Why do we introduce scope creep in this PR? I would suggest splitting the "... and change project structure" into a separate PR for discussion (NMS-13166).

[swachter]

Why do we introduce scope creep in this PR? I would suggest splitting the "... and change project structure" into a separate PR for discussion (NMS-13166).

First of: The ticket for this PR is NMS-13134 and not NMS-13166). Maybe this is the reasons for your comment?

The new project structure was discussed and announced at a couple of occasions. Therefore I did not expect that the switch from branches into modules is questioned.

Changing the project structure was merely creating a folder for es-7.6.2, moving the current sources in there and adjusting the poms. Should this be reviewed?

[swachter]

As long as ZIP plugins are still created, LGTM!

ZIPs are still generated. I am not sure if they are published, though. Is this a concern?

[agalue]

From my perspective, as part of the regular support process, I use Docker or Kubernetes to start an Elasticsearch cluster, and having a ZIP file is the easiest and fastest way to have the plugin required installed (as RPMs or DEB packages would introduce an unnecessary extra level of complexity in this case; even though for on-prem installations, that's the way to have the plugin installed). In my use case, not having that means I have to manually build it and use that instead of the official one.

[swachter]

From my perspective, as part of the regular support process, I use Docker or Kubernetes to start an Elasticsearch cluster, and having a ZIP file is the easiest and fastest way to have the plugin required installed

ZIP files will still be deployed.