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

Opensearch Modularization #1838

Open
2 of 7 tasks
rishabhmaurya opened this issue Jan 3, 2022 · 3 comments
Open
2 of 7 tasks

Opensearch Modularization #1838

rishabhmaurya opened this issue Jan 3, 2022 · 3 comments
Labels
enhancement Enhancement or improvement to existing feature or request Plugins Roadmap:Modular Architecture Project-wide roadmap label

Comments

@rishabhmaurya
Copy link
Contributor

rishabhmaurya commented Jan 3, 2022

Meta issue to track the progress of opensearch modularization.

@rishabhmaurya rishabhmaurya added enhancement Enhancement or improvement to existing feature or request untriaged labels Jan 3, 2022
@reta
Copy link
Collaborator

reta commented Jan 4, 2022

This is a large and disruptive one, I would recommend to start with cleaning up the packages since the same ones are scattered across many modules (so called split package issue). Probably the most challenging one is org.opensearch.client which is present in server, client:rest and client:rest-high-level, at least. I am sure there are more examples like that.

@rishabhmaurya
Copy link
Contributor Author

rishabhmaurya commented Jan 4, 2022

solving split packages in org.opensearch.client and modularizing will surely unblock customers using java 9 modules and the rest high level client and is a good starting point. The overall goal is to split server module and allow plugin to depend on these sub modules instead of server module. This will ensure plugins to compile and run successfully, if there are no major version upgrade in its dependencies, on opensearch major version release. Also, the packages exported by modules will be controlled, so plugins cannot depend on classes not exported explicitly. This is a big step for overall hygiene and maintainability for both opensearch and its plugins.

Taking incremental steps is the right thing but we need to ensure all breaking changes go at once in OpenSearch 2.0, so that plugins incorporate all breaking changes only once. We need to start thinking on right modules to start with and mark them as automatic module while migrating packages to them from server module, fixing split packages and cyclic dependencies.
Also, when there would be these sub-modules like org.opensearch.index or org.opensearch.analyzers etc, there would be even more split packages between these newly created modules and server module. Today, there are split packages between modules under lib and server module and also for org.apache.lucence between lucene modules and server module.

@reta
Copy link
Collaborator

reta commented Feb 9, 2022

@rishabhmaurya I think we should make this one a [META] issue since it also drags in other projects [1]

[1] opensearch-project/opensearch-java#108

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or improvement to existing feature or request Plugins Roadmap:Modular Architecture Project-wide roadmap label
Projects
None yet
Development

No branches or pull requests

4 participants