* What went wrong:
A problem occurred configuring root project 'logic-during-configuration-dont'.
> Could not create task ':printArtifactNames'.

	"sigs.k8s.io/structured-merge-diff/v4/fieldpath"
)

// serviceCIDRStrategy implements verification logic for ServiceCIDR allocators.
type serviceCIDRStrategy struct {
	runtime.ObjectTyper
	names.NameGenerator
}

// Strategy is the default logic that applies when creating and updating Replication ServiceCIDR objects.
var Strategy = serviceCIDRStrategy{legacyscheme.Scheme, names.SimpleNameGenerator}

3. You learned about dependency management in <<part3_gradle_dep_man#part3_begin,part 3>>.

== Step 1. Understanding Plugins
Plugins are the primary method to organize build logic and reuse build logic within a project.

Plugins are also used to distribute custom tasks as packaged code.

class GradleLifecycleIntegrationTest extends AbstractIntegrationSpec {

    def withSettingsPluginInBuildLogic() {
        settingsFile '''
            pluginManagement {
                includeBuild 'build-logic'
            }
            plugins {
                id 'my-settings-plugin'
            }
            dsl {
                parameter = "42"
            }
        '''
    }

# ADR-0004 - Introduce a UI architecture module to the core platform

## Date

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.

    The new logic will use the `ProxyConfig.Concurrency` setting (which can be configured mesh wide or per-pod), if set,
    and otherwise set concurrency based on the CPU limit allocated to the container
    For example, a limit of 2500m would set concurrency to 3.
    
    Prior to this release, sidecars followed this logic, but sometimes incorrectly determined the CPU limit.

plugins {
    id("gradlebuild.kotlin-shared-runtime")
}

description = "Provides Kotlin DSL code that is shared between build-logic and runtime"

dependencies {
    compileOnly(platform("gradlebuild:build-platform"))
    compileOnly(kotlin("stdlib"))
    compileOnly("org.ow2.asm:asm-tree")
    compileOnly("com.google.code.findbugs:jsr305")

We want to apply a set of code quality checking rules to both types of projects and configure some aspects specific to each type.


== Organizing build logic

The use case can be modelled by layering three separate plugins:

====
[.multi-language-sample]
=====
.Build logic layout
[source, kotlin]
----
├── convention-plugins
│   ├── build.gradle.kts
│   ├── settings.gradle.kts
│   ├── src
│   │   ├── main

We want to apply a set of code quality checking rules to both types of projects and configure some aspects specific to each type.


== Organizing build logic

The use case can be modelled by layering three separate plugins:

====
[.multi-language-sample]
=====
.Build logic layout
[source, kotlin]
----
├── convention-plugins
│   ├── build.gradle.kts
│   ├── settings.gradle.kts
│   ├── src
│   │   ├── main

Please be aware that these options disable the validation that makes execution parallel- and caching-safe when isolated projects is enabled,
so you may see some unexpected behaviour when using them.

== Build logic constraints

Isolated projects prevents build logic from accessing the state of another project. This includes:

* Using most methods on the `Project` type. A small number of methods that return immutable information about the project are allowed: