Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -138,7 +138,7 @@ We have a lot of mechanisms to help expedite towards an accepted PR. Here are so
- `@opensearch.internal`: Marks internal classes subject to rapid changes.
- `@opensearch.api`: Marks public-facing API classes with backward compatibility guarantees.
- `@opensearch.experimental`: Indicates rapidly changing [experimental code](./DEVELOPER_GUIDE.md#experimental-development).
5. *Employ sandbox for significant core changes*: Any new features or enhancements that make changes to core classes (e.g., search phases, codecs, or specialized lucene APIs) are more likely to. be merged if they are sandboxed. This can only be enabled on the java CLI (`-Dsandbox.enabled=true`).
5. *Employ sandbox for significant core changes*: Any new features or enhancements that make changes to core classes (e.g., search phases, codecs, or specialized lucene APIs) are more likely to be merged if they are sandboxed. Sandbox is disabled by default and can be enabled on the Java CLI with `-Dsandbox.enabled=true`.
6. *Micro-benchmark critical path*: This is a lesser known mechanism, but if you have critical path changes you're afraid will impact performance (the changes touch the garbage collector, heap, direct memory, or CPU) then including a [microbenchmark](https://github.com/opensearch-project/OpenSearch/tree/main/benchmarks) with your PR (and jfr or flamegraph results in the description) is a *GREAT IDEA* and will help expedite the review process.
7. *Test rigorously*: Ensure thorough testing ([OpenSearchTestCase](./test/framework/src/main/java/org/opensearch/test/OpenSearchTestCase.java) for unit tests, [OpenSearchIntegTestCase](./test/framework/src/main/java/org/opensearch/test/OpenSearchIntegTestCase.java) for integration & cluster tests, [OpenSearchRestTestCase](./test/framework/src/main/java/org/opensearch/test/rest/OpenSearchRestTestCase.java) for testing REST endpoint interfaces, and yaml tests with [ClientYamlTestSuiteIT](./rest-api-spec/src/yamlRestTest/java/org/opensearch/test/rest/ClientYamlTestSuiteIT.java) for REST integration tests)

Expand Down
6 changes: 3 additions & 3 deletions DEVELOPER_GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -313,11 +313,11 @@ Another example is the `discovery-gce` plugin. It is *vital* to folks running in

### `sandbox`

This is where the community can add experimental features in to OpenSearch. There are three directories inside the sandbox - `libs`, `modules` and `plugins` - which mirror the subdirectories in the project root and have the same guidelines for deciding on where a new feature goes. The artifacts from `libs` and `modules` will be automatically included in the **snapshot** distributions. Once a certain feature is deemed worthy to be included in the OpenSearch release, it will be promoted to the corresponding subdirectory in the project root. **Note**: The sandbox code do not have any other guarantees such as backwards compatibility or long term support and can be removed at any time.
This is where the community can add experimental features in to OpenSearch. There are three directories inside the sandbox - `libs`, `modules` and `plugins` - which mirror the subdirectories in the project root and have the same guidelines for deciding on where a new feature goes. The artifacts from `libs` and `modules` can be included in the **snapshot** distributions when sandbox is enabled. Once a certain feature is deemed worthy to be included in the OpenSearch release, it will be promoted to the corresponding subdirectory in the project root. **Note**: The sandbox code do not have any other guarantees such as backwards compatibility or long term support and can be removed at any time.

To exclude the modules from snapshot distributions, use the `sandbox.enabled` system property.
To include sandbox modules in snapshot distributions, use the `sandbox.enabled` system property.

./gradlew assemble -Dsandbox.enabled=false
./gradlew assemble -Dsandbox.enabled=true

### `qa`

Expand Down
4 changes: 2 additions & 2 deletions distribution/build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -241,8 +241,8 @@ project.rootProject.subprojects.findAll { it.parent.path == ':modules' }.each {
// copy all sandbox modules if the distribution is a snapshot
if (VersionProperties.isOpenSearchSnapshot()) {
Properties sysProps = System.getProperties();
// setting this property to false will exclude the sandbox modules from the distribution
final String enableSandbox = sysProps.getProperty("sandbox.enabled", "true");
// setting this property to true will include the sandbox modules in the distribution
final String enableSandbox = sysProps.getProperty("sandbox.enabled", "false");
if(sysProps != null && enableSandbox == "true") {
tasks.withType(NoticeTask).configureEach {
project(':sandbox:libs').subprojects.each { Project lib ->
Expand Down
39 changes: 30 additions & 9 deletions sandbox/build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -6,29 +6,50 @@
* compatible open source license.
*/

import org.gradle.api.publish.plugins.PublishingPlugin

/**
* This module provides a space in OpenSearch for the community to easily experiment with new ideas and innovate.
* Ideally, this is where an experimental features will reside before it can be promoted to the corresponding directory
* in the project root. The sandbox module contains three subdirectories, that mirror the root libs, modules and
* plugins directories, each with similar intention.
*
* All artifacts from the sandbox/libs and sandbox/modules will be included in the snapshot distributions automatically.
* All artifacts from the sandbox/libs and sandbox/modules can be included in the snapshot distributions.
* During assembling distributions, however, we will check if the following two conditions are met, for including the
* sandbox modules,

*
* 1. The distribution is a snapshot i.e. the build system property build.snapshot is set to true. We use this because,
* it will prevent accidental inclusion of these artifacts in a release distribution.
*
* 2. The sandbox.enabled system property is set to true. This new extra flag is added because we can exclude the
* modules from the snapshot distributions, if needed. For instance, we may want to run performance tests on snapshots
* without the sandbox modules.
* 2. The sandbox.enabled system property is set to true. This extra flag keeps sandbox artifacts disabled by default
* and allows opting in only when needed.
*
* To build the distributions without the sandbox modules,
* ./gradlew assemble -Dsandbox.enabled=false
* To build the distributions with the sandbox modules,
* ./gradlew assemble -Dsandbox.enabled=true
*
* Similarly we can run OpenSearch from source without the sandbox modules
* ./gradlew run -Dsandbox.enabled=false
* Similarly we can publish sandbox artifacts to Maven local with
* ./gradlew publishToMavenLocal -Dsandbox.enabled=true
*/
def sandboxEnabled = System.getProperty("sandbox.enabled", "false") == "true"

subprojects {
group = 'org.opensearch.sandbox'

if (sandboxEnabled == false) {
afterEvaluate {
tasks.configureEach { task ->
if (
task.group == PublishingPlugin.PUBLISH_TASK_GROUP
|| task.name.startsWith('generatePomFileFor')
|| task.name.startsWith('generateMetadataFileFor')
|| task.name == 'validatePom'
|| (task.name.startsWith('validate') && task.name.endsWith('Pom'))
) {
task.enabled = false
task.setDependsOn([])
task.onlyIf { false }
}
}
}
}
}
Loading