# ADR-0005 - 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.

An architecture module is responsible for providing a coherent set of features and:

- Provides a set of APIs and services for use from outside the module.
- Has a private implementation.
- Is owned by a single team. A team may own multiple architecture modules.

The modules are arranged into several different "Gradle platforms".

# Gradle architecture documentation

This directory contains documentation that describes Gradle's architecture and how the various pieces fit together and work.

## Architecture decision records (ADRs)

The Gradle team uses ADRs to record architectural decisions that the team has made.

See [Architecture decisions records](standards) for the list of ADRs.

# Cross-cutting architecture checks and decisions
.github/CODEOWNERS                          @gradle/bt-architecture-council
architecture/                               @gradle/bt-architecture-council
testing/architecture-test                   @gradle/bt-architecture-council

# These files change frequently, and changes to them don't need to automatically alert the architecture council

  -->

# Gradle platform architecture

Gradle is arranged into coarse-grained components called "architecture modules" and "platforms".
See [ADR4](standards/0004-use-a-platform-architecture.md) for a definition of these terms.

The diagram below shows the current set of architecture modules and platforms:

        attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(LibraryElements.CLASSES))
    }
}
notForAccessorGeneration {
    dependencies {
        sharedArchTestClasses(project(":internal-architecture-testing"))
    }
}

testing {
    suites {
        create("archTest", JvmTestSuite::class) {
            project.jvmCompile {
                addCompilationFrom(sources)
            }

	buildcfg.GOOS = "linux" // obj can handle this OS for all architectures.
	buildcfg.GOARCH = goarch
	architecture := arch.Set(goarch, false)
	if architecture == nil {
		panic("asm: unrecognized architecture " + goarch)
	}
	ctxt := obj.Linknew(architecture.LinkArch)
	ctxt.Pkgpath = "pkg"
	return architecture, ctxt
}

func newParser(goarch string) *Parser {
	architecture, ctxt := setArch(goarch)

the offsets being used to access them are correct.
</p>

<h2 id="architectures">Architecture-specific details</h2>

<p>
It is impractical to list all the instructions and other details for each machine.
To see what instructions are defined for a given machine, say ARM,
look in the source for the <code>obj</code> support library for
that architecture, located in the directory <code>src/cmd/internal/obj/arm</code>.

    val isWindows = OperatingSystem.current().isWindows
    val isLinux = OperatingSystem.current().isLinux
    val isMacOsX = OperatingSystem.current().isMacOsX
    val isIntel: Boolean = architecture == "x86_64" || architecture == "x86"
    val isSlowInternetConnection
        get() = System.getProperty("slow.internet.connection", "false")!!.toBoolean()
    val agentNum: Int
        get() {

// result against a golden file.

func testEndToEnd(t *testing.T, goarch, file string) {
	input := filepath.Join("testdata", file+".s")
	architecture, ctxt := setArch(goarch)
	architecture.Init(ctxt)
	lexer := lex.NewLexer(input)
	parser := NewParser(ctxt, architecture, lexer)
	pList := new(obj.Plist)
	var ok bool
	testOut = new(strings.Builder) // The assembler writes test output to this buffer.