public JapicmpTaskWithKotlin() {
        super();
        addKotlinCompilerToJapicmpClasspath();
        getMaxWorkerHeap().convention("1g");
    }

    // it's easier to do this via reflection than to copy the whole task
    private void addKotlinCompilerToJapicmpClasspath() {
        try {
            Field additionalJapicmpClasspathField = JapicmpTask.class.getDeclaredField("additionalJapicmpClasspath");

    if (name.endsWith("ToRemoteRepository")) {
        failEarlyIfUrlOrCredentialsAreNotSet(this)
        // packageBuild task executes tests, so we must run after it
        mustRunAfter(":packageBuild")
    }
}

@Suppress("ThrowsCount")
fun Project.failEarlyIfUrlOrCredentialsAreNotSet(publish: Task) {
    gradle.taskGraph.whenReady {
        if (hasTask(publish)) {
            if (artifactoryUrl.isEmpty()) {

	}
	return riscv.SPOP_END
}

// RISCV64ValidateVectorType reports whether the given configuration is a
// valid vector type.
func RISCV64ValidateVectorType(vsew, vlmul, vtail, vmask int64) error {
	_, err := riscv.EncodeVectorType(vsew, vlmul, vtail, vmask)
	return err

instead of using the same database session, you would create a new database session inside of the background task, and you would obtain the objects from the database using this new session. And then instead of passing the object from the database as a parameter to the background task function, you would pass the ID of that object and then obtain the object again inside the background task function....

Provider API, domain object containers) when defining configurable parts of a plugin (tasks, extensions, domain objects).  The Provider API provides a consistent way to set conventions, wire related configuration together (extension <- domain object <- task) and avoid evaluation ordering problems.

The Gradle codebase has evolved over time and has a mixture of simple getter/setter methods, Provider API and things in between.  It can be hard to follow best practices because Gradle provided types...

    /* the implementation class to collect information from task execution result */
    klass: Class<T>,
    /* which tasks we need to monitor? For example, cache-miss-monitor monitors `AbstractCompile` tasks */
    taskFilter: (Task) -> Boolean,
    /* pass the collected information in build-logic and main build to Build Scan */

        inactiveProfileIds.forEach(this::deactivateOptionalProfile);
    }

    /**
     * Mark a profile as required and activated.
     * @param id The identifier of the profile.
     */
    public void activateRequiredProfile(String id) {
        this.activations.put(id, ActivationSettings.activated());
    }

    /**
     * Mark a profile as optional and activated.
     * @param id The identifier of the profile.
     */

    }

    @Override
    public <T> Future<T> submit(Callable<T> task) {
      throw new UnsupportedOperationException();
    }

    @Override
    public Future<?> submit(Runnable task) {
      throw new UnsupportedOperationException();
    }

    @Override
    public <T> Future<T> submit(Runnable task, T result) {
      throw new UnsupportedOperationException();
    }

    @Override

package gradlebuild.binarycompatibility

import org.gradle.api.GradleException
import org.gradle.api.tasks.CacheableTask
import org.gradle.api.tasks.TaskAction
import java.io.File


/**
 * This [Task][org.gradle.api.Task] checks that the contents of a given accepted API changes files
 * are present in alphabetical order (by type, then member), and throws an exception and reports
 * any changes that are not.
 */
@CacheableTask

import org.apache.maven.project.MavenProject;

/**
 * @since 3.0
 */
public interface LifecycleExecutionPlanCalculator {
    MavenExecutionPlan calculateExecutionPlan(MavenSession session, MavenProject project, List<Task> tasks)
            throws PluginNotFoundException, PluginResolutionException, LifecyclePhaseNotFoundException,
                    PluginDescriptorParsingException, MojoNotFoundException, InvalidPluginDescriptorException,