reta
commented
4 hours ago (sharing the Slack discussion) I personally see no compelling reasons to publish core plugins to Maven repositories, because of the following:
- any core plugin could be downloaded for offline use (the URLs are stable and will be documented [1])
- the core plugins are in "preferred" position
a) the tooling installs them by name (fe
opensearch-pluging install transport-nio) b) they are signed and the signatures are verified
Although Maven layout may look convenient for OpenSearch core plugins (those are ZIPs btw), any single build tool available out there could be tailored to deal with offline dependencies.
[1] https://github.com/opensearch-project/documentation-website/issues/8763
Is your feature request related to a problem? Please describe
our build system does not have access to the internet. we can however fetch resources via maven (local server which proxies the requests) and are using this to fetch other plugins. however, i just noticed that this does not apply to core plugins (e.g. the newly introduced
analysis-phonenumber).Describe the solution you'd like
core plugins should, like other plugins (e.g. the security plugin) have their ZIP files published to maven central, so that they can be fetched via maven.
Related component
Plugins
Describe alternatives you've considered
if the URL for downloading plugins is stable and documented (the latter at least isn't the case yet: https://github.com/opensearch-project/documentation-website/issues/8763) it might be an option to configure the maven proxy to fetch files from there. we'd have to try that (it will also depend on the structure at the address where it has been published).
however, since the whole infrastructure for plugin ZIP publishing is in place in the opensearch ecosystem it'd probably be relatively easy to add the publishing step to the release?
Additional context
other plugin ZIPs are being published to maven since this issue has been implemented a while ago: https://github.com/opensearch-project/opensearch-build/issues/1916
CC @reta & @saratvemulapalli with whom i had discussed this already a bit on slack