honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/settings.gradle

116 lines
4.8 KiB
Groovy
Raw Normal View History

Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
import org.elasticsearch.gradle.Version
Build: Remove hardcoded reference to x-plugins in build (#21773) * Build: Remove hardcoded reference to x-plugins in build The gradle build currenlty allows extra plugins to be hooked into the elasticsearch build by placing under an x-plugins directory as a sibling of the elasticsearch checkout. This change converts this directory to one called elasticsearch-extra. The subdirectories of elasticsearch-extra become first level projects in gradle (while before they would have been subprojects of `:x-plugins`. Additionally, this allows major version checkouts to be associated with extra plugins. For example, you could have elasticsearch checked out as `elasticsearch-5.x`, and a sibling `elasticsearch-5.x-extra` directory.
2016-12-14 18:02:07 -05:00
String dirName = rootProject.projectDir.name
rootProject.name = dirName
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
Build: Fix eclipse generation to add a core-tests projects Eclipse does not have the ability to differentiate test dependencies from main dependencies. This causes what looks like a circular dependency through test-framework. This change sets up an additional core-tests project for eclipse only, which removes this problem.
2015-11-05 01:28:57 -05:00
List projects = [
Build: Add fake project to include buildSrc as normal project This is a follow up to #18173 and includes adding pom generation to the fake build-tools project, which is really just buildSrc, but builds during normal builds.
2016-05-07 01:22:38 -04:00
'build-tools',
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
'rest-api-spec',
Generate and run tests from the docs Adds infrastructure so `gradle :docs:check` will extract tests from snippets in the documentation and execute the tests. This is included in `gradle check` so it should happen on CI and during a normal build. By default each `// AUTOSENSE` snippet creates a unique REST test. These tests are executed in a random order and the cluster is wiped between each one. If multiple snippets chain together into a test you can annotate all snippets after the first with `// TEST[continued]` to have the generated tests for both snippets joined. Snippets marked as `// TESTRESPONSE` are checked against the response of the last action. See docs/README.asciidoc for lots more. Closes #12583. That issue is about catching bugs in the docs during build. This catches *some* bugs in the docs during build which is a good start.
2016-04-29 10:42:03 -04:00
'docs',
Group client projects under :client :client ---------> :client:rest :client-sniffer -> :client:sniffer :client-test ----> :client:test This lines the client up with how we do things like modules and plugins.
2016-06-22 13:40:01 -04:00
'client:rest',
add REST high level client gradle submodule and first simple method The RestHighLevelClient class takes as as an argument a low level client instance RestClient. The first method added is ping, which returns true if the call to HEAD / went ok and false if an IOException was thrown. Any other exception gets bubbled up. There are two kinds of tests, a unit test (RestHighLevelClientTests) that verifies the interaction between high level and low level client, and an integration test (MainActionIT) which relies on an externally started es cluster to send requests to.
2016-12-29 12:16:04 -05:00
'client:rest-high-level',
Group client projects under :client :client ---------> :client:rest :client-sniffer -> :client:sniffer :client-test ----> :client:test This lines the client up with how we do things like modules and plugins.
2016-06-22 13:40:01 -04:00
'client:sniffer',
Add a dedicated client/transport project for transport-client (#19435) The `client/transport` project adds a new jar build project that pulls in all dependencies and configures all required modules. Preinstalled modules are: * transport-netty * lang-mustache * reindex * percolator The `TransportClient` classes are still in core while `TransportClient.Builder` has only a protected construcutor such that users are redirected to use the new `TransportClientBuilder` from the new jar. Closes #19412
2016-07-18 09:42:24 -04:00
'client:transport',
Group client projects under :client :client ---------> :client:rest :client-sniffer -> :client:sniffer :client-test ----> :client:test This lines the client up with how we do things like modules and plugins.
2016-06-22 13:40:01 -04:00
'client:test',
Add client-benchmark-noop-api-plugin to stress clients even more in benchmarks (#20103)
2016-08-26 03:05:47 -04:00
'client:client-benchmark-noop-api-plugin',
Add client benchmark With this commit we add a benchmark for the new REST client and the existing transport client. Closes #19281
2016-07-26 05:01:22 -04:00
'client:benchmark',
Add microbenchmarking infrastructure (#18891) With this commit we add a benchmarks project that contains the necessary build infrastructure and an example benchmark. It is added as a separate project to avoid interfering with the regular build too much (especially sanity checks) and to keep the microbenchmarks isolated. Microbenchmarks are generated with `gradle :benchmarks:jmhJar` and can be run with ` gradle :benchmarks:jmh`. We intentionally do not use the [jmh-gradle-plugin](https://github.com/melix/jmh-gradle-plugin) as it causes all sorts of problems (dependencies are not properly excluded, not all JMH parameters can be set) and it adds another abstraction layer that is not needed. Closes #18242
2016-06-15 10:48:02 -04:00
'benchmarks',
Build: Group archive and package distribution projects (#28673) This commit adds intermediate gradle projects for archive based distributions (zip, tar) and package based distributions (rpm, deb). The grouping allows the common distribution build file to be considerably shorter and clearly separated from the common zip/tar and rpm/deb configuration.
2018-02-14 01:49:53 -05:00
'distribution:archives:integ-test-zip',
'distribution:archives:zip',
'distribution:archives:tar',
'distribution:packages:deb',
'distribution:packages:rpm',
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
'distribution:bwc:next-minor-snapshot',
'distribution:bwc:staged-minor-snapshot',
'distribution:bwc:next-bugfix-snapshot',
'distribution:bwc:maintenance-bugfix-snapshot',
Extend JVM options to support multiple versions JDK 9 has removed JVM options that were valid in JDK 8 (e.g., GC logging flags) and replaced them with new flags that are not available in JDK 8. This means that a single JVM options file can no longer apply to JDK 8 and JDK 9, complicating development, complicating our packaging story, and complicating operations. This commit extends the JVM options syntax to specify the range of versions the option applies to. If the running JVM matches the range of versions, the flag will be used to start the JVM otherwise the flag will be ignored. We implement this parser in Java for simplicity, and with this we start our first step towards a Java launcher. Relates #27675
2017-12-06 18:03:13 -05:00
'distribution:tools:launchers',
Build: Move plugin cli and tests to distribution tool (#24220) The plugin cli currently resides inside the elasticsearch jar. This commit moves it into a plugin-cli jar. This is change alone is a no-op; it does not change anything about what is loaded at runtime. But it will allow easier testing (with fixtures in the future to test ES or maven installation), as well as eventually not loading these classes when starting elasticsearch.
2017-04-21 12:25:58 -04:00
'distribution:tools:plugin-cli',
Rename core module to server (#28180) This is related to #27933. It renames the core module to server. This is the first step towards introducing an elasticsearch-core jar.
2018-01-11 13:30:43 -05:00
'server',
'server:cli',
Build: Move test framework under a "test" top level dir This allows adding more test projects, eg integ test fixtures that will be coming soon.
2015-12-17 19:57:39 -05:00
'test:framework',
Build: Add fixture capabilities to integ tests This change adds a Fixture class for use by gradle. A Fixture is an external process that integration tests will use. It can be added as a dependsOn for integTest, and will automatically be shutdown upon success or failure, as well as relevant information dumped on failure. There is also an example fixture in this change.
2015-12-15 23:14:37 -05:00
'test:fixtures:example-fixture',
Add MiniHDFS test fixture, started before integTest and shut down after. Currently uses a hardcoded port (9999), need to apply MavenFilteringHack after it starts.
2015-12-20 16:00:37 -05:00
'test:fixtures:hdfs-fixture',
Introduce Kerberos Test Fixture for Repository HDFS Security Tests (#24493) This PR introduces a subproject in test/fixtures that contains a Vagrantfile used for standing up a KRB5 KDC (Kerberos). The PR also includes helper scripts for provisioning principals, a few changes to the HDFS Fixture to allow it to interface with the KDC, as well as a new suite of integration tests for the HDFS Repository plugin. The HDFS Repository plugin senses if the local environment can support the HDFS Fixture (Windows is generally a restricted environment). If it can use the regular fixture, it then tests if Vagrant is installed with a compatible version to determine if the secure test fixtures should be enabled. If the secure tests are enabled, then we create a Kerberos KDC fixture, tasks for adding the required principals, and an HDFS fixture configured for security. A new integration test task is also configured to use the KDC and secure HDFS fixture and to run a testing suite that uses authentication. At the end of the secure integration test the fixtures are torn down.
2017-05-10 17:42:20 -04:00
'test:fixtures:krb5kdc-fixture',
Add qa module that tests reindex-from-remote against pre-5.0 versions of Elasticsearch (#24561) Adds tests for reindex-from-remote for the latest 2.4, 1.7, and 0.90 releases. 2.4 and 1.7 are fairly popular versions but 0.90 is a point of pride. This fixes any issues those tests revealed. Closes #23828 Closes #24520
2017-05-11 10:06:20 -04:00
'test:fixtures:old-elasticsearch',
Build: Automatically add projects under libs, qa, modules and plugins (#28279) This commit lessens the burden on configuring settings.gradle when new projects are added. In particular, this makes it trivial to move a plugin to a module (or vice versa).
2018-01-17 22:54:43 -05:00
'test:logger-usage'
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
]
Build: Automatically add projects under libs, qa, modules and plugins (#28279) This commit lessens the burden on configuring settings.gradle when new projects are added. In particular, this makes it trivial to move a plugin to a module (or vice versa).
2018-01-17 22:54:43 -05:00
/**
* Iterates over sub directories, looking for build.gradle, and adds a project if found
* for that dir with the given path prefix. Note that this requires each level
* of the dir hierarchy to have a build.gradle. Otherwise we would have to iterate
* all files/directories in the source tree to find all projects.
*/
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
void addSubProjects(String path, File dir) {
Build: Automatically add projects under libs, qa, modules and plugins (#28279) This commit lessens the burden on configuring settings.gradle when new projects are added. In particular, this makes it trivial to move a plugin to a module (or vice versa).
2018-01-17 22:54:43 -05:00
if (dir.isDirectory() == false) return;
if (dir.name == 'buildSrc') return;
if (new File(dir, 'build.gradle').exists() == false) return;
if (findProject(dir) != null) return;
final String projectName = "${path}:${dir.name}"
include projectName
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
if (path.isEmpty() || path.startsWith(':example-plugins')) {
Build: Automatically add projects under libs, qa, modules and plugins (#28279) This commit lessens the burden on configuring settings.gradle when new projects are added. In particular, this makes it trivial to move a plugin to a module (or vice versa).
2018-01-17 22:54:43 -05:00
project(projectName).projectDir = dir
}
for (File subdir : dir.listFiles()) {
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
addSubProjects(projectName, subdir)
Build: Automatically add projects under libs, qa, modules and plugins (#28279) This commit lessens the burden on configuring settings.gradle when new projects are added. In particular, this makes it trivial to move a plugin to a module (or vice versa).
2018-01-17 22:54:43 -05:00
}
}
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
Plugins: Add plugin extension capabilities (#27881) This commit adds the infrastructure to plugin building and loading to allow one plugin to extend another. That is, one plugin may extend another by the "parent" plugin allowing itself to be extended through java SPI. When all plugins extending a plugin are finished loading, the "parent" plugin has a callback (through the ExtensiblePlugin interface) allowing it to reload SPI. This commit also adds an example plugin which uses as-yet implemented extensibility (adding to the painless whitelist).
2018-01-03 14:12:43 -05:00
Build: Automatically add projects under libs, qa, modules and plugins (#28279) This commit lessens the burden on configuring settings.gradle when new projects are added. In particular, this makes it trivial to move a plugin to a module (or vice versa).
2018-01-17 22:54:43 -05:00
// include example plugins first, so adding plugin dirs below won't muck with :example-plugins
File examplePluginsDir = new File(rootProject.projectDir, 'plugins/examples')
for (File example : examplePluginsDir.listFiles()) {
if (example.isDirectory() == false) continue;
if (example.name.startsWith('build') || example.name.startsWith('.')) continue;
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
addSubProjects(':example-plugins', example)
Build: Automatically add projects under libs, qa, modules and plugins (#28279) This commit lessens the burden on configuring settings.gradle when new projects are added. In particular, this makes it trivial to move a plugin to a module (or vice versa).
2018-01-17 22:54:43 -05:00
}
project(':example-plugins').projectDir = new File(rootProject.projectDir, 'plugins/examples')
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
addSubProjects('', new File(rootProject.projectDir, 'libs'))
addSubProjects('', new File(rootProject.projectDir, 'modules'))
addSubProjects('', new File(rootProject.projectDir, 'plugins'))
addSubProjects('', new File(rootProject.projectDir, 'qa'))
Consolidate version numbering semantics (#27397) Fixes to the build system, particularly around BWC testing, and to make future version bumps less painful.
2017-11-21 03:26:45 -05:00
Build: Fix eclipse generation to add a core-tests projects Eclipse does not have the ability to differentiate test dependencies from main dependencies. This causes what looks like a circular dependency through test-framework. This change sets up an additional core-tests project for eclipse only, which removes this problem.
2015-11-05 01:28:57 -05:00
boolean isEclipse = System.getProperty("eclipse.launcher") != null || gradle.startParameter.taskNames.contains('eclipse') || gradle.startParameter.taskNames.contains('cleanEclipse')
if (isEclipse) {
// eclipse cannot handle an intermediate dependency between main and test, so we must create separate projects
Rename core module to server (#28180) This is related to #27933. It renames the core module to server. This is the first step towards introducing an elasticsearch-core jar.
2018-01-11 13:30:43 -05:00
// for server-src and server-tests
projects << 'server-tests'
Fix eclipse build. (#28236) Relates #28191
2018-01-16 04:50:07 -05:00
projects << 'libs:elasticsearch-core-tests'
Splits nio project into two for eclipse build only (#27939) * Splits nio project into two for eclipse build only https://github.com/elastic/elasticsearch/pull/27801 introduced a new gradle project `:libs:elasticsearch-nio` which creates cyclical project dependencies when importingthe projects into Eclipse. This change applies the same trick as we have for the core project where, and building for Eclipse, splits the `:libs:elasticsearch-nio` project into `:libs:elasticsearch-nio` which points to `src/main` and `:libs:elasticsearch-nio-tests` which points to `src/test`. This prevents cyclical project dependencies in Eclipse arising from the fact that eclipse does not separate compile/runtime dependencies from test dependencies. * Removes integTest bits since there are none
2017-12-21 09:34:15 -05:00
projects << 'libs:elasticsearch-nio-tests'
Fixes Eclipse build after secure-sm project was added (#28480)
2018-02-01 10:33:26 -05:00
projects << 'libs:secure-sm-tests'
Build: Fix eclipse generation to add a core-tests projects Eclipse does not have the ability to differentiate test dependencies from main dependencies. This causes what looks like a circular dependency through test-framework. This change sets up an additional core-tests project for eclipse only, which removes this problem.
2015-11-05 01:28:57 -05:00
}
include projects.toArray(new String[0])
Build: Add fake project to include buildSrc as normal project This is a follow up to #18173 and includes adding pom generation to the fake build-tools project, which is really just buildSrc, but builds during normal builds.
2016-05-07 01:22:38 -04:00
project(':build-tools').projectDir = new File(rootProject.projectDir, 'buildSrc')
Build: Fix eclipse generation to add a core-tests projects Eclipse does not have the ability to differentiate test dependencies from main dependencies. This causes what looks like a circular dependency through test-framework. This change sets up an additional core-tests project for eclipse only, which removes this problem.
2015-11-05 01:28:57 -05:00
if (isEclipse) {
Rename core module to server (#28180) This is related to #27933. It renames the core module to server. This is the first step towards introducing an elasticsearch-core jar.
2018-01-11 13:30:43 -05:00
project(":server").projectDir = new File(rootProject.projectDir, 'server/src/main')
project(":server").buildFileName = 'eclipse-build.gradle'
project(":server-tests").projectDir = new File(rootProject.projectDir, 'server/src/test')
project(":server-tests").buildFileName = 'eclipse-build.gradle'
Fix eclipse build. (#28236) Relates #28191
2018-01-16 04:50:07 -05:00
project(":libs:elasticsearch-core").projectDir = new File(rootProject.projectDir, 'libs/elasticsearch-core/src/main')
project(":libs:elasticsearch-core").buildFileName = 'eclipse-build.gradle'
project(":libs:elasticsearch-core-tests").projectDir = new File(rootProject.projectDir, 'libs/elasticsearch-core/src/test')
project(":libs:elasticsearch-core-tests").buildFileName = 'eclipse-build.gradle'
Splits nio project into two for eclipse build only (#27939) * Splits nio project into two for eclipse build only https://github.com/elastic/elasticsearch/pull/27801 introduced a new gradle project `:libs:elasticsearch-nio` which creates cyclical project dependencies when importingthe projects into Eclipse. This change applies the same trick as we have for the core project where, and building for Eclipse, splits the `:libs:elasticsearch-nio` project into `:libs:elasticsearch-nio` which points to `src/main` and `:libs:elasticsearch-nio-tests` which points to `src/test`. This prevents cyclical project dependencies in Eclipse arising from the fact that eclipse does not separate compile/runtime dependencies from test dependencies. * Removes integTest bits since there are none
2017-12-21 09:34:15 -05:00
project(":libs:elasticsearch-nio").projectDir = new File(rootProject.projectDir, 'libs/elasticsearch-nio/src/main')
project(":libs:elasticsearch-nio").buildFileName = 'eclipse-build.gradle'
project(":libs:elasticsearch-nio-tests").projectDir = new File(rootProject.projectDir, 'libs/elasticsearch-nio/src/test')
project(":libs:elasticsearch-nio-tests").buildFileName = 'eclipse-build.gradle'
Fixes Eclipse build after secure-sm project was added (#28480)
2018-02-01 10:33:26 -05:00
project(":libs:secure-sm").projectDir = new File(rootProject.projectDir, 'libs/secure-sm/src/main')
project(":libs:secure-sm").buildFileName = 'eclipse-build.gradle'
project(":libs:secure-sm-tests").projectDir = new File(rootProject.projectDir, 'libs/secure-sm/src/test')
project(":libs:secure-sm-tests").buildFileName = 'eclipse-build.gradle'
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
}
Change extra plugins to x-plugins directory instead of extra-plugin- prefix
2015-11-23 17:44:37 -05:00
// look for extra plugins for elasticsearch
Build: Remove hardcoded reference to x-plugins in build (#21773) * Build: Remove hardcoded reference to x-plugins in build The gradle build currenlty allows extra plugins to be hooked into the elasticsearch build by placing under an x-plugins directory as a sibling of the elasticsearch checkout. This change converts this directory to one called elasticsearch-extra. The subdirectories of elasticsearch-extra become first level projects in gradle (while before they would have been subprojects of `:x-plugins`. Additionally, this allows major version checkouts to be associated with extra plugins. For example, you could have elasticsearch checked out as `elasticsearch-5.x`, and a sibling `elasticsearch-5.x-extra` directory.
2016-12-14 18:02:07 -05:00
File extraProjects = new File(rootProject.projectDir.parentFile, "${dirName}-extra")
if (extraProjects.exists()) {
for (File extraProjectDir : extraProjects.listFiles()) {
Generalize BWC logic (#28505) Generalizing BWC building so that there is less code to modify for a release. This ensures we do not need to think about what major or minor version is in the gradle code. It follows the general rules of the elastic release structure. For more information on the rules, see the VersionCollection's javadoc. This also removes the additional bwc snapshots that will never be released, such as 6.0.2, which were being built and tested against every time we ran bwc tests. Additionally, it creates 4 new projects that correspond to the different types of snapshots that may exist for a given version. Its possible to now run those individual tasks to work out bwc logic whereas previously it was impossible and the entire suite of bwc tests had to be run to work out any logic changes in the build tools' bwc project. Please note that if the project does not make sense for the version that is current, that an error will be thrown from that individual project if an attempt is made to run it. This should allow for automating the version bumps as well, since it removes all the hardcoded version logic from the configs.
2018-02-09 15:55:10 -05:00
addSubProjects('', extraProjectDir)
Change extra plugins to x-plugins directory instead of extra-plugin- prefix
2015-11-23 17:44:37 -05:00
}
Build: Group archive and package distribution projects (#28673) This commit adds intermediate gradle projects for archive based distributions (zip, tar) and package based distributions (rpm, deb). The grouping allows the common distribution build file to be considerably shorter and clearly separated from the common zip/tar and rpm/deb configuration.
2018-02-14 01:49:53 -05:00
}