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

29 lines
1.1 KiB
Groovy
Raw Normal View History

Build: Replace references to x-pack-elasticsearch paths with helper methods (elastic/x-pack-elasticsearch#3748) In order to more easily integrate xpack once it moves into the elasticsearch repo, references to the existing x-pack-elasticsearch need to be reduced. This commit introduces a few helper "methods" available to any project within xpack (through gradle project extension properties, as closures). All refeerences to project paths now use these helper methods, except for those pertaining to bwc, which will be handled in a followup. Original commit: elastic/x-pack-elasticsearch@850668744c7188f3ca8d6ff561c99fbd8995288e
2018-01-27 00:48:30 -05:00
import org.elasticsearch.gradle.plugin.PluginBuildPlugin
Moved directories around Original commit: elastic/x-pack-elasticsearch@2018bb5f9fe306e67418627851b2d712d6fcba8c
2016-09-29 06:03:14 -04:00
import org.elasticsearch.gradle.precommit.LicenseHeadersTask
Build: Add kibana x-pack and uber x-pack to gradle build Original commit: elastic/x-pack-elasticsearch@bea95ec32d519f9b96d9da6d9333784067a2e1f9
2016-04-25 19:21:05 -04:00
Build: Replace references to x-pack-elasticsearch paths with helper methods (elastic/x-pack-elasticsearch#3748) In order to more easily integrate xpack once it moves into the elasticsearch repo, references to the existing x-pack-elasticsearch need to be reduced. This commit introduces a few helper "methods" available to any project within xpack (through gradle project extension properties, as closures). All refeerences to project paths now use these helper methods, except for those pertaining to bwc, which will be handled in a followup. Original commit: elastic/x-pack-elasticsearch@850668744c7188f3ca8d6ff561c99fbd8995288e
2018-01-27 00:48:30 -05:00
Project xpackRootProject = project
Build: Disable publishing to sonatype, until we have it configured correctly Original commit: elastic/x-pack-elasticsearch@081be69ed73ae50177fe33c41c52038d5b4998b4
2016-02-04 16:07:01 -05:00
subprojects {
Rename folder x-pack-core -> core (elastic/x-pack-elasticsearch#3305) * Rename folder x-pack-core -> core The jar remains 'x-pack-core-*.jar' * Put group in top-level build.gradle instead of plugin/core/build.gradle Original commit: elastic/x-pack-elasticsearch@b23452fa553ca1b1636c64295a7ea3a5874d79df
2017-12-12 15:23:29 -05:00
group = 'org.elasticsearch.plugin'
Build: Replace references to x-pack-elasticsearch paths with helper methods (elastic/x-pack-elasticsearch#3748) In order to more easily integrate xpack once it moves into the elasticsearch repo, references to the existing x-pack-elasticsearch need to be reduced. This commit introduces a few helper "methods" available to any project within xpack (through gradle project extension properties, as closures). All refeerences to project paths now use these helper methods, except for those pertaining to bwc, which will be handled in a followup. Original commit: elastic/x-pack-elasticsearch@850668744c7188f3ca8d6ff561c99fbd8995288e
2018-01-27 00:48:30 -05:00
ext.xpackRootProject = xpackRootProject
ext.xpackProject = { String projectName -> xpackRootProject.project(projectName) }
// helper method to find the path to a module
ext.xpackModule = { String moduleName -> xpackProject("plugin:${moduleName}").path }
Rename folder x-pack-core -> core (elastic/x-pack-elasticsearch#3305) * Rename folder x-pack-core -> core The jar remains 'x-pack-core-*.jar' * Put group in top-level build.gradle instead of plugin/core/build.gradle Original commit: elastic/x-pack-elasticsearch@b23452fa553ca1b1636c64295a7ea3a5874d79df
2017-12-12 15:23:29 -05:00
Build: Replace references to x-pack-elasticsearch paths with helper methods (elastic/x-pack-elasticsearch#3748) In order to more easily integrate xpack once it moves into the elasticsearch repo, references to the existing x-pack-elasticsearch need to be reduced. This commit introduces a few helper "methods" available to any project within xpack (through gradle project extension properties, as closures). All refeerences to project paths now use these helper methods, except for those pertaining to bwc, which will be handled in a followup. Original commit: elastic/x-pack-elasticsearch@850668744c7188f3ca8d6ff561c99fbd8995288e
2018-01-27 00:48:30 -05:00
plugins.withType(PluginBuildPlugin).whenPluginAdded {
Reorganize license files This commit moves the apache and elastic license files into a new root level `licenses` directory and rewrites the top level LICENSE.txt to clarify the repository has a mix of apache and elastic licensed code.
2018-04-10 16:58:49 -04:00
project.esplugin.licenseFile = rootProject.file('licenses/ELASTIC-LICENSE.txt')
Build: Replace references to x-pack-elasticsearch paths with helper methods (elastic/x-pack-elasticsearch#3748) In order to more easily integrate xpack once it moves into the elasticsearch repo, references to the existing x-pack-elasticsearch need to be reduced. This commit introduces a few helper "methods" available to any project within xpack (through gradle project extension properties, as closures). All refeerences to project paths now use these helper methods, except for those pertaining to bwc, which will be handled in a followup. Original commit: elastic/x-pack-elasticsearch@850668744c7188f3ca8d6ff561c99fbd8995288e
2018-01-27 00:48:30 -05:00
project.esplugin.noticeFile = xpackRootProject.file('NOTICE.txt')
Build: Configure the license/notice file for xpack (elastic/x-pack-elasticsearch#2357) This commit uses the new license/notice file settings in gradle to specify the xpack license to be placed in jar files. See https://github.com/elastic/elasticsearch/pull/26373 Original commit: elastic/x-pack-elasticsearch@209a1e9a47d1da870cb17e2b86821ec6b07bf7b2
2017-08-25 01:47:10 -04:00
}
HLRC XPack Protocol clean up: Migration; Graph; Watcher (#34639) Move parts related to XPack for packages Migration; Graph; Watcher from protocol to client Drop protocol module Relates #34451
2018-10-29 08:38:56 -04:00
tasks.withType(LicenseHeadersTask.class) {
approvedLicenses = ['Elastic License', 'Generated']
additionalLicense 'ELAST', 'Elastic License', 'Licensed under the Elastic License'
}
HLREST: Add x-pack-info API (#31870) This is the first x-pack API we're adding to the high level REST client so there is a lot to talk about here! = Open source The *client* for these APIs is open source. We're taking the previously Elastic licensed files used for the `Request` and `Response` objects and relicensing them under the Apache 2 license. The implementation of these features is staying under the Elastic license. This lines up with how the rest of the Elasticsearch language clients work. = Location of the new files We're moving all of the `Request` and `Response` objects that we're relicensing to the `x-pack/protocol` directory. We're adding a copy of the Apache 2 license to the root fo the `x-pack/protocol` directory to line up with the language in the root `LICENSE.txt` file. All files in this directory will have the Apache 2 license header as well. We don't want there to be any confusion. Even though the files are under the `x-pack` directory, they are Apache 2 licensed. We chose this particular directory layout because it keeps the X-Pack stuff together and easier to think about. = Location of the API in the REST client We've been following the layout of the rest-api-spec files for other APIs and we plan to do this for the X-Pack APIs with one exception: we're dropping the `xpack` from the name of most of the APIs. So `xpack.graph.explore` will become `graph().explore()` and `xpack.license.get` will become `license().get()`. `xpack.info` and `xpack.usage` are special here though because they don't belong to any proper category. For now I'm just calling `xpack.info` `xPackInfo()` and intend to call usage `xPackUsage` though I'm not convinced that this is the final name for them. But it does get us started. = Jars, jars everywhere! This change makes the `xpack:protocol` project a `compile` scoped dependency of the `x-pack:plugin:core` and `client:rest-high-level` projects. I intend to keep it a compile scoped dependency of `x-pack:plugin:core` but I intend to bundle the contents of the protocol jar into the `client:rest-high-level` jar in a follow up. This change has grown large enough at this point. In that followup I'll address javadoc issues as well. = Breaking-Java This breaks that transport client by a few classes around. We've traditionally been ok with doing this to the transport client.
2018-07-08 11:03:56 -04:00
HLRC XPack Protocol clean up: Migration; Graph; Watcher (#34639) Move parts related to XPack for packages Migration; Graph; Watcher from protocol to client Drop protocol module Relates #34451
2018-10-29 08:38:56 -04:00
ext.licenseName = 'Elastic License'
ext.licenseUrl = ext.elasticLicenseUrl
HLREST: Add x-pack-info API (#31870) This is the first x-pack API we're adding to the high level REST client so there is a lot to talk about here! = Open source The *client* for these APIs is open source. We're taking the previously Elastic licensed files used for the `Request` and `Response` objects and relicensing them under the Apache 2 license. The implementation of these features is staying under the Elastic license. This lines up with how the rest of the Elasticsearch language clients work. = Location of the new files We're moving all of the `Request` and `Response` objects that we're relicensing to the `x-pack/protocol` directory. We're adding a copy of the Apache 2 license to the root fo the `x-pack/protocol` directory to line up with the language in the root `LICENSE.txt` file. All files in this directory will have the Apache 2 license header as well. We don't want there to be any confusion. Even though the files are under the `x-pack` directory, they are Apache 2 licensed. We chose this particular directory layout because it keeps the X-Pack stuff together and easier to think about. = Location of the API in the REST client We've been following the layout of the rest-api-spec files for other APIs and we plan to do this for the X-Pack APIs with one exception: we're dropping the `xpack` from the name of most of the APIs. So `xpack.graph.explore` will become `graph().explore()` and `xpack.license.get` will become `license().get()`. `xpack.info` and `xpack.usage` are special here though because they don't belong to any proper category. For now I'm just calling `xpack.info` `xPackInfo()` and intend to call usage `xPackUsage` though I'm not convinced that this is the final name for them. But it does get us started. = Jars, jars everywhere! This change makes the `xpack:protocol` project a `compile` scoped dependency of the `x-pack:plugin:core` and `client:rest-high-level` projects. I intend to keep it a compile scoped dependency of `x-pack:plugin:core` but I intend to bundle the contents of the protocol jar into the `client:rest-high-level` jar in a follow up. This change has grown large enough at this point. In that followup I'll address javadoc issues as well. = Breaking-Java This breaks that transport client by a few classes around. We've traditionally been ok with doing this to the transport client.
2018-07-08 11:03:56 -04:00
HLRC XPack Protocol clean up: Migration; Graph; Watcher (#34639) Move parts related to XPack for packages Migration; Graph; Watcher from protocol to client Drop protocol module Relates #34451
2018-10-29 08:38:56 -04:00
project.ext.licenseFile = rootProject.file('licenses/ELASTIC-LICENSE.txt')
project.ext.noticeFile = xpackRootProject.file('NOTICE.txt')
Build: Disable publishing to sonatype, until we have it configured correctly Original commit: elastic/x-pack-elasticsearch@081be69ed73ae50177fe33c41c52038d5b4998b4
2016-02-04 16:07:01 -05:00
}