import japicmp.model.JApiMethod;
import me.champeau.gradle.japicmp.report.Violation;

import java.util.Map;

public class NewIncubatingAPIRule extends AbstractGradleViolationRule {

    public NewIncubatingAPIRule(Map<String, Object> params) {
        super(params);
    }

    @Override
    public Violation maybeViolation(final JApiCompatibility member) {

import japicmp.model.JApiCompatibility
import japicmp.model.JApiMethod
import me.champeau.gradle.japicmp.report.Violation

@CompileStatic
class KotlinModifiersBreakingChangeRule extends AbstractGradleViolationRule {

    KotlinModifiersBreakingChangeRule(Map<String, Object> params) {
        super(params)
    }

    @Override
    Violation maybeViolation(JApiCompatibility member) {

    id: context
    attributes:
      label: Context (optional)
      description: |
        How has this issue affected you? What are you trying to accomplish?
        Providing context helps us come up with a solution that is most useful in the real world
    validations:

This is a collection of best practices for Gradle implementation.
Should and should not do's.

## Error messages and suggestions

Traditionally, if an error occurred, the error message and the possible solution were provided to the console via a single String in the corresponding exception.
That meant possible solutions for Problems could be scattered all over the console output.

    id: context
    attributes:
      label: Context (optional)
      description: |
        How has this issue affected you? What are you trying to accomplish?
        Providing context helps us come up with a solution that is most useful in the real world
    validations:
      required: false
  - type: textarea
    id: steps-to-reproduce
    attributes:
      label: Steps to Reproduce
      description: |

        return repository.isOverride(method)
    }

    Violation acceptOrReject(JApiCompatibility member, Violation rejection) {
        List<String> changes = member.compatibilityChanges.collect { Violation.describe(it) }
        return acceptOrReject(member, changes, rejection)
    }

    Violation acceptOrReject(JApiCompatibility member, List<String> changes, Violation rejection) {

      env:
        # Set the DEVELOCITY_ACCESS_KEY so that Gradle Build Scans are generated
        DEVELOCITY_ACCESS_KEY: ${{ secrets.GRADLE_ENTERPRISE_ACCESS_KEY }}
        # Potential stop-gap solution for ReadTimeout issues with the Gradle Build Cache
        # https://gradle.slack.com/archives/CHDLT99C6/p1636477584059200
        GRADLE_OPTS: -Dhttp.keepAlive=false

    - name: Compile with Gradle without Build Scan

            }
        }

        if (!errors.isEmpty()) {
            def changes = errors + warnings
            return acceptOrReject(member, changes, Violation.error(member, changes.join(" ")))
        }
        if (!warnings.isEmpty()) {
            return Violation.warning(member, warnings.join(" "))
        }
        return null
    }

    private static List<Boolean> parametersNullabilityOf(CtBehavior behavior) {

                }
            """

        def rule = withContext(new SinceAnnotationMissingRule([:]))

        then:
        def violation = rule.maybeViolation(jApiType)
        violation.severity == Severity.error
        violation.humanExplanation =~ 'Is not annotated with @since 11.38'

        where:
        apiElement          | jApiTypeName
        'method'            | 'jApiMethod'

* Keep commits discrete. Avoid including multiple unrelated changes in a single commit.
* Keep commits self-contained. Avoid spreading a single change across multiple commits. A single commit should make sense in isolation.

### Testing changes

After making changes, you can test your code in 2 ways:

1. Run tests.
- Run `./gradlew :<subproject>:quickTest` where `<subproject>` is the name of the subproject you've changed.