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.

  *
  * The intended use is that this data model can be populated with the complete information of a project prior to any
  * report logic running.  This enables the reporting logic to remain completely independent of the actual project classes.
 */
public final class ConfigurationReportModel {
    private final String projectName;
    private final List<ReportConfiguration> allConfigs;

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")

.github/                                    @gradle/bt-developer-productivity @gradle/bt-support # This might need to be more finegrained in the future
/build-logic/                               @gradle/bt-developer-productivity
/build-logic-commons/                       @gradle/bt-developer-productivity
/build-logic-settings/                      @gradle/bt-developer-productivity
/build.gradle*                              @gradle/bt-developer-productivity

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:

== Organizing build logic

From the use case above, we have identified that we have two types of projects - generic Java projects and public libraries.
We can model this use case by layering two separate plugins that each define the type of project that applies them:

====
[.multi-language-sample]
=====
.Build logic layout
[source, kotlin]
----
├── buildSrc
│   ├── build.gradle.kts