Is your feature request related to a problem?

Extensions may depend on each other. See #108

Identifying dependencies in the extensions themselves requires unique resolution of the actual dependency, which is not possible without a globally unique extension ID. This also creates a significant challenge in preventing circular dependencies where A depends on B, B depends on C, and C depends on A (or shorter or longer chains).

Presently the uniqueId field is being used in the extensions.yml file to provide a unique (for that OpenSearch installation) user-controlled short name for extensions. This name can also be used to define dependencies in that same file.

What solution would you like?

Create a new class ExtensionDependency containing at least two fields: a uniqueId and a minimum version (following semver).

Update the extensions.yml file and its associated writeable class DiscoveryExtension to add an optional List<ExtensionDependency> dependencies field.

• If the field is omitted, defaults to an empty list
• If the field is present with one entry, creates a singleton list
• If the field is present with multiple entries, creates a list

Extension initialization order (see ExtensionsOrchestrator.extensionsDiscovery() method) follows the ordering in extensions.yml. Validate the dependent unique IDs during this initialization by tracking the IDs that have already been seen and logging an error when this occurs, including enough details for the user to resolve it themselves.

In the Extension (ExtensionsRunner class), save the unique IDs of dependent extensions to an instance variable to enable them to pass that ID to OpenSearch at a later time.

What alternatives have you considered?

Enforcing extension dependency via existing java ecosystem methods (repository modules, reverse dns package names). While this approach doesn't prevent such use (e.g., to use classes in another extension) it requires a lot of overhead to enforce in simple situations where just having a (unique) extension name is sufficient.

Having a separate dependency resolution module (e.g., gradle or maven) is very complicated.

Do you have any additional context?

May relate to #149, in which rather than getting all extensions, only dependent initialized extensions are returned. This implementation decision can be deferred until both capabilities are implemented.