## Date

2024-01-12

## Context

Gradle's public API requires equal access from all JVM-based languages.
Kotlin, Groovy, Java and other JVM-based languages should be able to use the Gradle API without relying on another language's standard library.

Historically, Gradle has shipped with some Groovy types in very prominent APIs.

  - commit

automations:

  summary_table:
    if:
      - {{ is.requested or not pr.author_is_org_member }}
      - {{ author.using_gitstream or not pr.author_is_org_member }}
    run:
      - action: add-comment@v1
        args:
          comment:
            <h3>Change Summary</h3>
            This PR is {{ changes.ratio | round(2) }}% new code.
            <table>
            <tr>
            <td>Platform</td>

# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  summary_table_platforms:
    if:
      - {{ ('summary_table_platforms' | isEnabledAutomation(pr)) }}
    run:
      - action: add-comment@v1
        args:
          comment: |
            {{ by_platform_comment }}

by_platform_comment: |

## Date

2024-01-12

## Context

Gradle's public API requires equal access from all JVM-based languages.
Kotlin, Groovy, Java, and other JVM-based languages should be able to use the Gradle API without relying on another language's standard library.

Historically, Gradle has shipped with some Groovy types in very prominent APIs.

## Before you start

Before starting to work on a feature or a bug fix, please open an issue to discuss the use case or bug with us. This can save everyone a lot of time and frustration.

For any non-trivial change, we need to be able to answer these questions:

* 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?