For example, each process has different supported JVMs and a different set of services available for dependency injection.
While a lot of Gradle source code runs only in the Gradle daemon, not all of it does and so, when working on some source code it is important to be aware of the runtimes in which it will run.

See [Gradle runtimes](runtimes.md) for a list of these runtimes and more details.

**Experimental!**

We'd like to capture our architectural decisions about the build tool as [Architectural Decision Records (ADRs)](https://adr.github.io/).
For now we just have this global repository of ADRs.
If we see fit, we can break these out to per-platform ones, or keep a hybrid approach to having global and platform-specific ADSs.

Our aim is to keep the process lightweight and approachable.

* [Building Swift Libraries](https://docs.gradle.org/current/samples/sample_building_swift_libraries.html)
* [Creating Build Scans](https://scans.gradle.com/)

## Stay in Flow
Enjoy first-class Gradle support in your IDE of choice.

* [Android Studio](https://developer.android.com/studio/build/index.html)
* [Eclipse](https://www.vogella.com/tutorials/EclipseGradle/article.html)
* [IntelliJ IDEA](https://www.jetbrains.com/help/idea/gradle.html)

## Open & import the project

In your IDEA, `File` - `Open`, select `.teamcity/pom.xml`, `import as project`, and you'll have a Maven project.

## Project structure

Mostly a standard Maven project structure. The entry point `settings.kts` defines the TeamCity project.

There are 3 subprojects in the TeamCity project hierarchy: `Check` for Gradle builds, `Promotion` for releasing Gradle versions, `Util` for miscellaneous utilities.