Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
|
|
|
|
|
* or more contributor license agreements. Licensed under the Elastic License
|
|
|
|
|
* 2.0 and the Server Side Public License, v 1; you may not use this file except
|
|
|
|
|
* in compliance with, at your election, the Elastic License 2.0 or the Server
|
|
|
|
|
* Side Public License, v 1.
|
|
|
|
|
*/
|
|
|
|
|
|
2023-01-12 22:42:49 +08:00
|
|
|
import org.elasticsearch.index.codec.tsdb.ES87TSDBDocValuesFormat;
|
|
|
|
|
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
/** The Elasticsearch Server Module. */
|
|
|
|
|
module org.elasticsearch.server {
|
|
|
|
|
requires java.logging;
|
|
|
|
|
requires java.security.jgss;
|
|
|
|
|
requires java.sql;
|
|
|
|
|
requires java.management;
|
|
|
|
|
requires jdk.unsupported;
|
2023-02-07 21:18:25 +08:00
|
|
|
requires java.net.http; // required by ingest-geoip's dependency maxmind.geoip2 https://github.com/elastic/elasticsearch/issues/93553
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
|
|
|
|
|
requires org.elasticsearch.cli;
|
|
|
|
|
requires org.elasticsearch.base;
|
|
|
|
|
requires org.elasticsearch.geo;
|
|
|
|
|
requires org.elasticsearch.lz4;
|
|
|
|
|
requires org.elasticsearch.pluginclassloader;
|
|
|
|
|
requires org.elasticsearch.securesm;
|
|
|
|
|
requires org.elasticsearch.xcontent;
|
2022-06-13 16:25:54 +08:00
|
|
|
requires org.elasticsearch.logging;
|
2023-01-14 16:49:37 +08:00
|
|
|
requires org.elasticsearch.plugin;
|
|
|
|
|
requires org.elasticsearch.plugin.analysis;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
|
|
|
|
|
requires com.sun.jna;
|
|
|
|
|
requires hppc;
|
|
|
|
|
requires HdrHistogram;
|
|
|
|
|
requires jopt.simple;
|
|
|
|
|
requires log4j2.ecs.layout;
|
|
|
|
|
requires org.lz4.java;
|
|
|
|
|
requires t.digest;
|
|
|
|
|
|
|
|
|
|
requires org.apache.logging.log4j;
|
|
|
|
|
requires org.apache.logging.log4j.core;
|
|
|
|
|
|
|
|
|
|
requires org.apache.lucene.analysis.common;
|
|
|
|
|
requires org.apache.lucene.backward_codecs;
|
|
|
|
|
requires org.apache.lucene.core;
|
|
|
|
|
requires org.apache.lucene.grouping;
|
|
|
|
|
requires org.apache.lucene.highlighter;
|
|
|
|
|
requires org.apache.lucene.join;
|
|
|
|
|
requires org.apache.lucene.memory;
|
|
|
|
|
requires org.apache.lucene.misc;
|
|
|
|
|
requires org.apache.lucene.queries;
|
|
|
|
|
requires org.apache.lucene.queryparser;
|
|
|
|
|
requires org.apache.lucene.sandbox;
|
|
|
|
|
requires org.apache.lucene.suggest;
|
|
|
|
|
|
|
|
|
|
exports org.elasticsearch;
|
|
|
|
|
exports org.elasticsearch.action;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.allocation;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.configuration;
|
2022-12-12 17:23:15 +08:00
|
|
|
exports org.elasticsearch.action.admin.cluster.coordination;
|
2022-06-20 21:32:44 +08:00
|
|
|
exports org.elasticsearch.action.admin.cluster.desirednodes;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.action.admin.cluster.health;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.migration;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.node.hotthreads;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.node.info;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.node.reload;
|
2022-11-16 20:44:00 +08:00
|
|
|
exports org.elasticsearch.action.admin.cluster.node.shutdown;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.action.admin.cluster.node.stats;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.node.tasks.cancel;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.node.tasks.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.node.tasks.list;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.node.usage;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.remote;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.repositories.cleanup;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.repositories.delete;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.repositories.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.repositories.put;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.repositories.verify;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.reroute;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.settings;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.shards;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.clone;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.create;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.delete;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.features;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.get.shard;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.restore;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.snapshots.status;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.state;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.stats;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.storedscripts;
|
|
|
|
|
exports org.elasticsearch.action.admin.cluster.tasks;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.alias;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.alias.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.analyze;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.cache.clear;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.close;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.create;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.dangling;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.dangling.delete;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.dangling.find;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.dangling.import_index;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.dangling.list;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.delete;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.diskusage;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.flush;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.forcemerge;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.mapping.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.mapping.put;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.open;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.readonly;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.recovery;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.refresh;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.resolve;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.rollover;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.segments;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.settings.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.settings.put;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.shards;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.shrink;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.stats;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.template.delete;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.template.get;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.template.post;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.template.put;
|
|
|
|
|
exports org.elasticsearch.action.admin.indices.validate.query;
|
|
|
|
|
exports org.elasticsearch.action.bulk;
|
|
|
|
|
exports org.elasticsearch.action.datastreams;
|
|
|
|
|
exports org.elasticsearch.action.delete;
|
|
|
|
|
exports org.elasticsearch.action.explain;
|
|
|
|
|
exports org.elasticsearch.action.fieldcaps;
|
|
|
|
|
exports org.elasticsearch.action.get;
|
|
|
|
|
exports org.elasticsearch.action.index;
|
|
|
|
|
exports org.elasticsearch.action.ingest;
|
|
|
|
|
exports org.elasticsearch.action.main;
|
|
|
|
|
exports org.elasticsearch.action.resync;
|
|
|
|
|
exports org.elasticsearch.action.search;
|
|
|
|
|
exports org.elasticsearch.action.support;
|
|
|
|
|
exports org.elasticsearch.action.support.broadcast;
|
|
|
|
|
exports org.elasticsearch.action.support.broadcast.node;
|
2023-02-15 18:46:06 +08:00
|
|
|
exports org.elasticsearch.action.support.broadcast.unpromotable;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.action.support.master;
|
|
|
|
|
exports org.elasticsearch.action.support.master.info;
|
|
|
|
|
exports org.elasticsearch.action.support.nodes;
|
|
|
|
|
exports org.elasticsearch.action.support.replication;
|
|
|
|
|
exports org.elasticsearch.action.support.single.instance;
|
|
|
|
|
exports org.elasticsearch.action.support.single.shard;
|
|
|
|
|
exports org.elasticsearch.action.support.tasks;
|
|
|
|
|
exports org.elasticsearch.action.termvectors;
|
|
|
|
|
exports org.elasticsearch.action.update;
|
|
|
|
|
exports org.elasticsearch.bootstrap;
|
|
|
|
|
exports org.elasticsearch.client.internal;
|
|
|
|
|
exports org.elasticsearch.client.internal.node;
|
|
|
|
|
exports org.elasticsearch.client.internal.support;
|
|
|
|
|
exports org.elasticsearch.client.internal.transport;
|
|
|
|
|
exports org.elasticsearch.cluster;
|
|
|
|
|
exports org.elasticsearch.cluster.ack;
|
|
|
|
|
exports org.elasticsearch.cluster.action.index;
|
|
|
|
|
exports org.elasticsearch.cluster.action.shard;
|
|
|
|
|
exports org.elasticsearch.cluster.block;
|
|
|
|
|
exports org.elasticsearch.cluster.coordination;
|
2023-03-31 19:27:46 +08:00
|
|
|
exports org.elasticsearch.cluster.coordination.stateless;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.cluster.health;
|
|
|
|
|
exports org.elasticsearch.cluster.metadata;
|
|
|
|
|
exports org.elasticsearch.cluster.node;
|
|
|
|
|
exports org.elasticsearch.cluster.routing;
|
|
|
|
|
exports org.elasticsearch.cluster.routing.allocation;
|
|
|
|
|
exports org.elasticsearch.cluster.routing.allocation.allocator;
|
|
|
|
|
exports org.elasticsearch.cluster.routing.allocation.command;
|
|
|
|
|
exports org.elasticsearch.cluster.routing.allocation.decider;
|
|
|
|
|
exports org.elasticsearch.cluster.service;
|
|
|
|
|
exports org.elasticsearch.common;
|
|
|
|
|
exports org.elasticsearch.common.blobstore;
|
|
|
|
|
exports org.elasticsearch.common.blobstore.fs;
|
|
|
|
|
exports org.elasticsearch.common.blobstore.support;
|
|
|
|
|
exports org.elasticsearch.common.breaker;
|
|
|
|
|
exports org.elasticsearch.common.bytes;
|
|
|
|
|
exports org.elasticsearch.common.cache;
|
|
|
|
|
exports org.elasticsearch.common.cli;
|
|
|
|
|
exports org.elasticsearch.common.collect;
|
|
|
|
|
exports org.elasticsearch.common.component;
|
|
|
|
|
exports org.elasticsearch.common.compress;
|
|
|
|
|
exports org.elasticsearch.common.document;
|
|
|
|
|
exports org.elasticsearch.common.filesystem;
|
|
|
|
|
exports org.elasticsearch.common.geo;
|
|
|
|
|
exports org.elasticsearch.common.hash;
|
|
|
|
|
exports org.elasticsearch.common.inject;
|
|
|
|
|
exports org.elasticsearch.common.inject.binder;
|
|
|
|
|
exports org.elasticsearch.common.inject.internal;
|
|
|
|
|
exports org.elasticsearch.common.inject.matcher;
|
|
|
|
|
exports org.elasticsearch.common.inject.multibindings;
|
|
|
|
|
exports org.elasticsearch.common.inject.name;
|
|
|
|
|
exports org.elasticsearch.common.inject.spi;
|
|
|
|
|
exports org.elasticsearch.common.inject.util;
|
|
|
|
|
exports org.elasticsearch.common.io;
|
|
|
|
|
exports org.elasticsearch.common.io.stream;
|
|
|
|
|
exports org.elasticsearch.common.logging;
|
|
|
|
|
exports org.elasticsearch.common.lucene;
|
|
|
|
|
exports org.elasticsearch.common.lucene.index;
|
|
|
|
|
exports org.elasticsearch.common.lucene.search;
|
|
|
|
|
exports org.elasticsearch.common.lucene.search.function;
|
|
|
|
|
exports org.elasticsearch.common.lucene.store;
|
|
|
|
|
exports org.elasticsearch.common.lucene.uid;
|
|
|
|
|
exports org.elasticsearch.common.metrics;
|
|
|
|
|
exports org.elasticsearch.common.network;
|
|
|
|
|
exports org.elasticsearch.common.path;
|
|
|
|
|
exports org.elasticsearch.common.recycler;
|
|
|
|
|
exports org.elasticsearch.common.regex;
|
2023-02-17 16:55:40 +08:00
|
|
|
exports org.elasticsearch.common.scheduler;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.common.settings;
|
|
|
|
|
exports org.elasticsearch.common.text;
|
|
|
|
|
exports org.elasticsearch.common.time;
|
|
|
|
|
exports org.elasticsearch.common.transport;
|
|
|
|
|
exports org.elasticsearch.common.unit;
|
|
|
|
|
exports org.elasticsearch.common.util;
|
|
|
|
|
exports org.elasticsearch.common.util.concurrent;
|
|
|
|
|
exports org.elasticsearch.common.util.iterable;
|
|
|
|
|
exports org.elasticsearch.common.util.set;
|
|
|
|
|
exports org.elasticsearch.common.xcontent;
|
|
|
|
|
exports org.elasticsearch.common.xcontent.support;
|
|
|
|
|
exports org.elasticsearch.discovery;
|
|
|
|
|
exports org.elasticsearch.env;
|
|
|
|
|
exports org.elasticsearch.gateway;
|
|
|
|
|
exports org.elasticsearch.health;
|
2022-08-03 16:10:26 +08:00
|
|
|
exports org.elasticsearch.health.node;
|
2022-06-20 17:48:59 +08:00
|
|
|
exports org.elasticsearch.health.node.selection;
|
Collect health API stats (#91559)
This PR introduces the collectors of the health API telemetry. Our
target telemetry has the following shape:
```
{
"invocations": {
"total": 22,
"verbose_true": 12,
"verbose_false": 10
},
"statuses": {
"green": 10,
"yellow": 4,
"red": 8,
"values": ["green", "yellow", "red"]
},
"indicators": {
"red" : {
"master_stability": 2,
"ilm":2,
"slm": 4,
"values": ["master_stability", "ilm", "slm"]
},
"yellow": {
"disk": 1,
"shards_availability": 1,
"master_stability": 2,
"values": ["disk", "shards_availability", "master_stability"]
}
},
"diagnoses": {
"red": {
"elasticsearch:health:shards_availability:primary_unassigned": 1,
"elasticsearch:health:disk:add_disk_capacity_master_nodes": 3,
"values": ["elasticsearch:health:shards_availability:primary_unassigned", "elasticsearch:health:disk:add_disk_capacity_master_nodes"]
},
"yellow": {
"elasticsearch:health:disk:add_disk_capacity_data_nodes": 1,
"values": [""elasticsearch:health:disk:add_disk_capacity_data_nodes"]
}
}
}
```
This PR introduces the thread safe `Counters` class and the
`HealthApiStats` which keeps keeps of the metrics above based on the
health api responses that it encounters. The `HealthApiStatsAction`
collects the `HealthApiStats` of all nodes.
Part of: #90877
2022-11-18 18:34:33 +08:00
|
|
|
exports org.elasticsearch.health.stats;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.http;
|
|
|
|
|
exports org.elasticsearch.index;
|
|
|
|
|
exports org.elasticsearch.index.analysis;
|
|
|
|
|
exports org.elasticsearch.index.bulk.stats;
|
|
|
|
|
exports org.elasticsearch.index.cache;
|
|
|
|
|
exports org.elasticsearch.index.cache.bitset;
|
|
|
|
|
exports org.elasticsearch.index.cache.query;
|
|
|
|
|
exports org.elasticsearch.index.cache.request;
|
|
|
|
|
exports org.elasticsearch.index.codec;
|
2023-01-12 22:42:49 +08:00
|
|
|
exports org.elasticsearch.index.codec.tsdb;
|
2022-08-08 23:14:26 +08:00
|
|
|
exports org.elasticsearch.index.codec.bloomfilter;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.index.engine;
|
|
|
|
|
exports org.elasticsearch.index.fielddata;
|
|
|
|
|
exports org.elasticsearch.index.fielddata.fieldcomparator;
|
|
|
|
|
exports org.elasticsearch.index.fielddata.ordinals;
|
|
|
|
|
exports org.elasticsearch.index.fielddata.plain;
|
|
|
|
|
exports org.elasticsearch.index.fieldvisitor;
|
|
|
|
|
exports org.elasticsearch.index.flush;
|
|
|
|
|
exports org.elasticsearch.index.get;
|
|
|
|
|
exports org.elasticsearch.index.mapper;
|
|
|
|
|
exports org.elasticsearch.index.mapper.flattened;
|
2022-06-23 12:10:20 +08:00
|
|
|
exports org.elasticsearch.index.mapper.vectors;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.index.merge;
|
|
|
|
|
exports org.elasticsearch.index.query;
|
|
|
|
|
exports org.elasticsearch.index.query.functionscore;
|
|
|
|
|
exports org.elasticsearch.index.query.support;
|
|
|
|
|
exports org.elasticsearch.index.recovery;
|
|
|
|
|
exports org.elasticsearch.index.refresh;
|
|
|
|
|
exports org.elasticsearch.index.reindex;
|
|
|
|
|
exports org.elasticsearch.index.search;
|
|
|
|
|
exports org.elasticsearch.index.search.stats;
|
|
|
|
|
exports org.elasticsearch.index.seqno;
|
|
|
|
|
exports org.elasticsearch.index.shard;
|
|
|
|
|
exports org.elasticsearch.index.similarity;
|
|
|
|
|
exports org.elasticsearch.index.snapshots;
|
|
|
|
|
exports org.elasticsearch.index.snapshots.blobstore;
|
|
|
|
|
exports org.elasticsearch.index.stats;
|
|
|
|
|
exports org.elasticsearch.index.store;
|
|
|
|
|
exports org.elasticsearch.index.termvectors;
|
|
|
|
|
exports org.elasticsearch.index.translog;
|
|
|
|
|
exports org.elasticsearch.index.warmer;
|
|
|
|
|
exports org.elasticsearch.indices;
|
|
|
|
|
exports org.elasticsearch.indices.analysis;
|
|
|
|
|
exports org.elasticsearch.indices.breaker;
|
|
|
|
|
exports org.elasticsearch.indices.cluster;
|
|
|
|
|
exports org.elasticsearch.indices.fielddata.cache;
|
|
|
|
|
exports org.elasticsearch.indices.recovery;
|
|
|
|
|
exports org.elasticsearch.indices.recovery.plan;
|
|
|
|
|
exports org.elasticsearch.indices.store;
|
|
|
|
|
exports org.elasticsearch.ingest;
|
|
|
|
|
exports org.elasticsearch.lucene.analysis.miscellaneous;
|
|
|
|
|
exports org.elasticsearch.lucene.grouping;
|
|
|
|
|
exports org.elasticsearch.lucene.queries;
|
|
|
|
|
exports org.elasticsearch.lucene.search.uhighlight;
|
|
|
|
|
exports org.elasticsearch.lucene.search.vectorhighlight;
|
|
|
|
|
exports org.elasticsearch.lucene.similarity;
|
|
|
|
|
exports org.elasticsearch.lucene.util;
|
|
|
|
|
exports org.elasticsearch.monitor;
|
|
|
|
|
exports org.elasticsearch.monitor.fs;
|
|
|
|
|
exports org.elasticsearch.monitor.jvm;
|
|
|
|
|
exports org.elasticsearch.monitor.os;
|
|
|
|
|
exports org.elasticsearch.monitor.process;
|
|
|
|
|
exports org.elasticsearch.node;
|
|
|
|
|
exports org.elasticsearch.persistent;
|
|
|
|
|
exports org.elasticsearch.persistent.decider;
|
|
|
|
|
exports org.elasticsearch.plugins;
|
|
|
|
|
exports org.elasticsearch.plugins.interceptor to org.elasticsearch.security;
|
|
|
|
|
exports org.elasticsearch.plugins.spi;
|
|
|
|
|
exports org.elasticsearch.repositories;
|
|
|
|
|
exports org.elasticsearch.repositories.blobstore;
|
|
|
|
|
exports org.elasticsearch.repositories.fs;
|
2022-12-12 17:23:15 +08:00
|
|
|
exports org.elasticsearch.reservedstate;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.rest;
|
|
|
|
|
exports org.elasticsearch.rest.action;
|
|
|
|
|
exports org.elasticsearch.rest.action.admin.cluster;
|
|
|
|
|
exports org.elasticsearch.rest.action.admin.cluster.dangling;
|
|
|
|
|
exports org.elasticsearch.rest.action.admin.indices;
|
|
|
|
|
exports org.elasticsearch.rest.action.cat;
|
|
|
|
|
exports org.elasticsearch.rest.action.document;
|
|
|
|
|
exports org.elasticsearch.rest.action.ingest;
|
|
|
|
|
exports org.elasticsearch.rest.action.search;
|
|
|
|
|
exports org.elasticsearch.script;
|
|
|
|
|
exports org.elasticsearch.script.field;
|
2022-06-23 12:10:20 +08:00
|
|
|
exports org.elasticsearch.script.field.vectors;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.search;
|
|
|
|
|
exports org.elasticsearch.search.aggregations;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.composite;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.filter;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.geogrid;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.global;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.histogram;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.missing;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.nested;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.range;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.sampler;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.terms;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.bucket.terms.heuristic;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.metrics;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.pipeline;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.support;
|
|
|
|
|
exports org.elasticsearch.search.aggregations.support.values;
|
|
|
|
|
exports org.elasticsearch.search.builder;
|
|
|
|
|
exports org.elasticsearch.search.collapse;
|
|
|
|
|
exports org.elasticsearch.search.dfs;
|
|
|
|
|
exports org.elasticsearch.search.fetch;
|
|
|
|
|
exports org.elasticsearch.search.fetch.subphase;
|
|
|
|
|
exports org.elasticsearch.search.fetch.subphase.highlight;
|
|
|
|
|
exports org.elasticsearch.search.internal;
|
|
|
|
|
exports org.elasticsearch.search.lookup;
|
|
|
|
|
exports org.elasticsearch.search.profile;
|
|
|
|
|
exports org.elasticsearch.search.profile.aggregation;
|
2022-10-06 00:54:36 +08:00
|
|
|
exports org.elasticsearch.search.profile.dfs;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.search.profile.query;
|
|
|
|
|
exports org.elasticsearch.search.query;
|
|
|
|
|
exports org.elasticsearch.search.rescore;
|
|
|
|
|
exports org.elasticsearch.search.runtime;
|
|
|
|
|
exports org.elasticsearch.search.searchafter;
|
|
|
|
|
exports org.elasticsearch.search.slice;
|
|
|
|
|
exports org.elasticsearch.search.sort;
|
|
|
|
|
exports org.elasticsearch.search.suggest;
|
|
|
|
|
exports org.elasticsearch.search.suggest.completion;
|
|
|
|
|
exports org.elasticsearch.search.suggest.completion.context;
|
|
|
|
|
exports org.elasticsearch.search.suggest.phrase;
|
|
|
|
|
exports org.elasticsearch.search.suggest.term;
|
2022-06-23 12:10:20 +08:00
|
|
|
exports org.elasticsearch.search.vectors;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.shutdown;
|
|
|
|
|
exports org.elasticsearch.snapshots;
|
|
|
|
|
exports org.elasticsearch.tasks;
|
|
|
|
|
exports org.elasticsearch.threadpool;
|
2022-07-26 04:01:41 +08:00
|
|
|
exports org.elasticsearch.tracing;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
exports org.elasticsearch.transport;
|
|
|
|
|
exports org.elasticsearch.upgrades;
|
|
|
|
|
exports org.elasticsearch.usage;
|
|
|
|
|
exports org.elasticsearch.watcher;
|
|
|
|
|
|
|
|
|
|
opens org.elasticsearch.common.logging to org.apache.logging.log4j.core;
|
|
|
|
|
|
Introduce a _lifecycle/explain API for data stream backing indices (#94621)
This adds an {index}/_lifecycle/explain API to retrieve information
about an index's status within its lifecycle.
The response looks like so:
```
"indices" : {
".ds-metrics-foo-2023.03.22-000001" : {
"index" : ".ds-metrics-foo-2023.03.22-000001",
"managed_by_dlm" : true,
"index_creation_date_millis" : 1679475563571,
"time_since_index_creation" : "843ms",
"rollover_date_millis" : 1679475564293,
"time_since_rollover" : "121ms",
"lifecycle" : { },
"generation_time" : "121ms"
},
".ds-metrics-foo-2023.03.22-000002" : {
"index" : ".ds-metrics-foo-2023.03.22-000002",
"managed_by_dlm" : true,
"index_creation_date_millis" : 1679475564351,
"time_since_index_creation" : "63ms",
"lifecycle" : { }
}
}
}
```
2023-03-27 15:44:40 +08:00
|
|
|
exports org.elasticsearch.action.dlm;
|
|
|
|
|
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
provides java.util.spi.CalendarDataProvider with org.elasticsearch.common.time.IsoCalendarDataProvider;
|
|
|
|
|
provides org.elasticsearch.xcontent.ErrorOnUnknown with org.elasticsearch.common.xcontent.SuggestingErrorOnUnknown;
|
|
|
|
|
provides org.elasticsearch.xcontent.XContentBuilderExtension with org.elasticsearch.common.xcontent.XContentElasticsearchExtension;
|
|
|
|
|
provides org.elasticsearch.cli.CliToolProvider
|
|
|
|
|
with
|
|
|
|
|
org.elasticsearch.cluster.coordination.NodeToolCliProvider,
|
|
|
|
|
org.elasticsearch.index.shard.ShardToolCliProvider;
|
2022-07-05 00:12:49 +08:00
|
|
|
|
2022-07-14 03:05:39 +08:00
|
|
|
uses org.elasticsearch.reservedstate.ReservedClusterStateHandlerProvider;
|
2023-04-11 04:05:43 +08:00
|
|
|
uses org.elasticsearch.jdk.ModuleQualifiedExportsService;
|
2022-08-08 23:14:26 +08:00
|
|
|
|
2023-02-04 20:42:26 +08:00
|
|
|
provides org.apache.lucene.codecs.PostingsFormat
|
|
|
|
|
with
|
|
|
|
|
org.elasticsearch.index.codec.bloomfilter.ES85BloomFilterPostingsFormat,
|
|
|
|
|
org.elasticsearch.index.codec.bloomfilter.ES87BloomFilterPostingsFormat;
|
2023-01-12 22:42:49 +08:00
|
|
|
provides org.apache.lucene.codecs.DocValuesFormat with ES87TSDBDocValuesFormat;
|
Modularize Elasticsearch (#81066)
This PR represents the initial phase of Modularizing Elasticsearch (with
Java Modules).
This initial phase modularizes the core of the Elasticsearch server
with Java Modules, which is then used to load and configure extension
components atop the server. Only a subset of extension components are
modularized at this stage (other components come in a later phase).
Components are loaded dynamically at runtime with custom class loaders
(same as is currently done). Components with a module-info.class are
defined to a module layer.
This architecture is somewhat akin to the Modular JDK, where
applications run on the classpath. In the analogy, the Elasticsearch
server modules are the platform (thus are always resolved and present),
while components without a module-info.class are non-modular code
running atop the Elasticsearch server modules. The extension components
cannot access types from non-exported packages of the server modules, in
the same way that classpath applications cannot access types from
non-exported packages of modules from the JDK. Broadly, the core
Elasticseach java modules simply "wrap" the existing packages and export
them. There are opportunites to export less, which is best done in more
narrowly focused follow-up PRs.
The Elasticsearch distribution startup scripts are updated to put jars
on the module path (the class path is empty), so the distribution will
run the core of the server as java modules. A number of key components
have been retrofitted with module-info.java's too, and the remaining
components can follow later. Unit and functional tests run as
non-modular (since they commonly require package-private access), while
higher-level integration tests, that run the distribution, run as
modular.
Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co>
Co-authored-by: Ryan Ernst <ryan@iernst.net>
Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
|
|
|
}
|
