# Using Gradle 8.4 Configuration Roles for Safe Cross-Project Data Aggregation

DevFeed: [Using Gradle 8.4 Configuration Roles for Safe Cross-Project Data Aggregation](<https://devfeed.tech/articles/configuration-roles-and-the-blogging-industrial-complex-30459.md>)

Original publisher: [Read original article](<https://dev.to/autonomousapps/configuration-roles-and-the-blogging-industrial-complex-21mn>)

Author: Tony Robalik

Published: 2023-10-17T21:52:27Z

Content type: tutorial

Language: en

Sources: [DEV Community: Tony Robalik](<https://devfeed.tech/sources/dev-community-tony-robalik.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [configuration](<https://devfeed.tech/topics/configuration.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

This tutorial explains Gradle 8.4's API for creating role-focused, immutable Configuration instances. It explores the three Configuration roles and demonstrates using them to publish and aggregate data from subprojects at the root project while preserving project boundaries.

## Source excerpt

On the perils of getting what you ask for Or, building cool stuff and making everyone think you're a wizard Gradle 8.4 has released an exciting new feature, an API for easily creating role-focused Configurations. For those who have been around the block a few times, it is well-known that the Configuration interface is amongst the most confusing in Gradle lore, not to mention having a very overloaded name. It also has many responsibilities and a massive memory footprint. The new API is meant as a step towards disambiguation. The new methods on ConfigurationContainer (aka configurations) are designed to simplify the creation of immutable, purpose-built Configuration instances. They do that. But they also expose complexity that was previously obscured by the prior legacy situation. On the plus side, this additional complexity is a boon to bloggers and build engineers eager to justify their (my) existence. All of the code used in this post is available on Github. First a warning Most Gradle projects won't need this kind of setup, and most Gradle plugins won't require this elaboration of responsibilities in the Configurations they create. The primary use-case is for ecosystem plugins (aka "core" plugins), but what we'll do here is also fairly common. Even if you don't need this yourself, understanding Configurations more deeply can be very valuable. What to expect if you keep reading A brief exploration of the three kinds of Configuration types, an explanation of how to use them, and a dip of the toes in the deep waters of safe cross-project publishing and aggregation. To guide our exploration, we will consider a concrete use-case. We want to be able to aggregate data from all subprojects at the root project (a natural location), and we want to do it in a safe way that doesn't violate project boundaries. Here's how we want our build scripts to look: // aggregator/build.gradle (or root build.gradle) plugins { id 'org.jetbrains.kotlin.jvm' id 'mutual.aid.configuration-role