return this;
    }

    /**
     * Gets the name of the featureset.
     *
     * @return The featureset name.
     */
    public String featureSetName() {
        return featureSetName;
    }

    /**
     * Sets the name of the featureset.
     *
     * @param featureSetName The featureset name.
     * @return This query builder.
     */

        DocumentBuilderFactory.newInstance().apply {
            setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)
            setFeature("http://xml.org/sax/features/external-general-entities", false)
            setFeature("http://xml.org/sax/features/external-parameter-entities", false)
            setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false)
            isExpandEntityReferences = false

Examples of properties in this category:

* `org.gradle.configuration-cache.parallel`

### Properties of stable features

Properties of stable features MUST start with `org.gradle.<feature-name>.`

The qualifier is absent for these properties, making the name more concise.
This is a sensible default, as the majority of features are of this nature.

These properties MUST be stable.

    "crossVersionTests": false
  },
  {
    "name": "project-features",
    "path": "platforms/core-configuration/project-features",
    "unitTests": false,
    "functionalTests": true,
    "crossVersionTests": false
  },
  {
    "name": "project-features-api",
    "path": "platforms/core-configuration/project-features-api",
    "unitTests": false,
    "functionalTests": false,

* Why is this change done? What's the use case?
* For user-facing features, what will the API look like?
* What test cases should it have? What could go wrong?
* How will it roughly be implemented? We'll happily provide code pointers to save you time.

We may ask you to answer these questions directly in the GitHub issue or (for large changes) in a shared Google Doc.

In addition, some of these discussions included proposals for having a single Java version supported by the Gradle Launcher and Daemon.
However, this would limit the ability of the Gradle ecosystem plugin authors to take advantage of new Java features and improvements.

One example is when one of the most popular plugins started requiring Java 17 because the underlying framework behind the plugin began requiring 17, and code from the framework was used in the plugin itself.

        "platforms/documentation/docs/src/docs/release/release-notes-assets/",
        "subprojects/launcher/src/main/resources/release-features.txt",
        "platforms/core-runtime/launcher/src/main/resources/release-features.txt"
    ));

    public static void main(String[] args) throws Exception {
        if (args.length != 0) {

**Web Crawling**:
- **Admin Path**: Crawler > Web
- **Supports**: HTTP/HTTPS websites
- **Features**: JavaScript rendering, authentication, custom headers

**File Crawling**:
- **Admin Path**: Crawler > File
- **Supports**: SMB, FTP, local file systems
- **Features**: Access control, file type filtering

**Data Store Crawling**:
- **Admin Path**: Crawler > Data Store

    val crossVersionTests: List<OsAwareBaseGradleBuildType>

    val docsTestTriggers: List<OsAwareBaseGradleBuildType>

    val flakyTestQuarantineTriggers: List<OsAwareBaseGradleBuildType>

    init {
        features {
            buildReportTab("Problems Report", "problems-report.html")
            if (stage.specificBuilds.contains(SpecificBuild.SanityCheck)) {
                buildReportTab(
                    "API Compatibility Report",

) : OsAwareBaseGradleBuildType(os = Os.LINUX, stage = stage, init = {
        id(buildTypeId(model))
        name = "Build-logic checks"
        description = "Run check on all build-logic builds"

        features {
            publishBuildStatusToGithub(model)
        }

        applyDefaults(
            model,
            this,
            "checkBuildLogic",
            extraParameters =
                listOf(