files=".*[/\\]platforms[/\\]core-configuration[/\\]base-diagnostics[/\\]src[/\\]main[/\\]java[/\\]org[/\\]gradle[/\\]api[/\\]plugins[/\\][^/\\]+"/>
    <suppress checks="JavadocPackage"
              files=".*[/\\]platforms[/\\]core-configuration[/\\]base-diagnostics[/\\]src[/\\]main[/\\]java[/\\]org[/\\]gradle[/\\]api[/\\]tasks[/\\]diagnostics[/\\][^/\\]+"/>

    <suppress checks="JavadocPackage"

        }
      },
      {
        "subprojects": [
          "antlr",
          "base-diagnostics",
          "file-watching",
          "ide",
          "ide-native",
          "kotlin-dsl",
          "platform-base",
          "plugins-application",
          "plugins-java-library",
          "software-diagnostics",
          "test-kit"
        ],
        "parallelizationMethod": {

## Status

- ACCEPTED on 2024-02-07

## Context

The Gradle core platform provides many services to the Gradle platforms and builds logic. One such group of services allows logic to interact with the build user, to provide diagnostics, progress information, prompt for questions, and so on. Currently, these services are part of the core platform runtime architecture module.

A downside of this structure is that it is difficult to do focused work on the Gradle UI.

    "path": "platforms/software/base-compiler-worker",
    "unitTests": false,
    "functionalTests": false,
    "crossVersionTests": false
  },
  {
    "name": "base-diagnostics",
    "path": "platforms/core-configuration/base-diagnostics",
    "unitTests": true,
    "functionalTests": true,
    "crossVersionTests": false
  },
  {
    "name": "base-ide-plugins",
    "path": "platforms/ide/base-ide-plugins",

            <option value="$PROJECT_DIR$/packaging/public-api" />
            <option value="$PROJECT_DIR$/platforms/core-configuration/api-metadata" />
            <option value="$PROJECT_DIR$/platforms/core-configuration/base-diagnostics" />
            <option value="$PROJECT_DIR$/platforms/core-configuration/base-services-groovy" />
            <option value="$PROJECT_DIR$/platforms/core-configuration/bean-serialization-services" />

                writeFessConfig(zos, diagnosticId);
                writeFesenCat(zos, diagnosticId);
                writeFesenJson(zos, diagnosticId);
            }
        });
    }

    /**
     * Writes OpenSearch JSON API responses to the ZIP output stream.
     *
     * @param zos the ZIP output stream to write to
     * @param id the diagnostic ID for organizing files in the ZIP

If the intention is to gather user feedback on an early prototype, then the experimental property should be used.
If the intention is to allow an issue reporter to get additional local diagnostics when running a build in their proprietary environment, then the internal property is sufficient.

Examples of properties that follow the naming rules:

* `org.gradle.experimental.declarative-common`

labels.number_of_shards_for_doc=Number of Shards
labels.auto_expand_replicas_for_doc=Auto-expand Replicas
labels.clear_crawler_index=Crawler Index
labels.clear_crawler_index_button=Delete Crawler Index
labels.diagnostic_logs=Diagnostics
labels.download_diagnostic_logs_button=Download Logs
labels.reload_doc_index=Reload Document Index
labels.reload_doc_index_button=Reload
labels.rebuild_config_index=Rebuild Config Index

labels.number_of_shards_for_doc=Number of Shards
labels.auto_expand_replicas_for_doc=Auto-expand Replicas
labels.clear_crawler_index=Crawler Index
labels.clear_crawler_index_button=Delete Crawler Index
labels.diagnostic_logs=Diagnostics
labels.download_diagnostic_logs_button=Download Logs
labels.reload_doc_index=Reload Document Index
labels.reload_doc_index_button=Reload
labels.rebuild_config_index=Rebuild Config Index

    /** The key of the message: Delete Crawler Index */
    public static final String LABELS_clear_crawler_index_button = "{labels.clear_crawler_index_button}";

    /** The key of the message: Diagnostics */
    public static final String LABELS_diagnostic_logs = "{labels.diagnostic_logs}";

    /** The key of the message: Download Logs */