It seems that Gradle 8 enforces that 2 configuration cannot have the same attributes. In my project I am seeing this issue:

Consumable configurations with identical capabilities within a project (other than the default configuration) must have unique attributes, but configuration ':bootArchives' and [configuration ':archives'] contain identical attribute sets. Consider adding an additional attribute to one of the configurations to disambiguate them. Run the 'outgoingVariants' task for more details. See https://docs.gradle.org/8.0.2/userguide/upgrading_version_7.html#unique_attribute_sets for more details.

I suggest adding an attribute for the bootArchives configuration that will distinguish between the two.

Perhaps leverage the bundling attribute and set it to embedded. https://docs.gradle.org/current/userguide/variant_attributes.html#sec:standard_attributes

Comment From: wilkinsona

Thanks for the suggestion. It sounds good to me. Ideally, we'd fix this in Boot 2.7 where we're aiming to support Gradle 8. I'm a little wary of accidentally regressing something so I've reached out to the Gradle team for their advice. I'd like to wait a little while to see what they say before processing here.

Comment From: wilkinsona

The Gradle team have told us that they're moving towards deprecating and removing archives and recommended that we follow suit with bootArchives if at all possible:

I think its important to consider the purpose of bootArchives — maybe you can shed some light for me there. Is this configuration meant to be selected by other projects during dependency resolution? Looking at the spring boot docs, it seems this configuration is also sort of being used as a “middle-man”. Is is possible to avoid the configuration entirely by directly wiring things together? In the long term I would advise this route.

If removing bootArchives altogether is not feasible, you should be able to avoid this message by adding either an attribute or a capability to this configuration in order to make its attributes+capabilities unique across all consumable configurations in a project. Choosing the proper values here is tricky though, since these values are meant to be set in the context of dependency resolution — and it looks like the the bootArchives configuration isn’t meant to participate in dependency resolution at all.

Taking a step back, looking at the code that produces the error we're not sure how you're getting it. Furthermore, we haven't seen it in Boot's test suite which tests against 8.0.2. To help us to better understand the situation that you're in, can you please provide a minimal sample that reproduces the error?

Comment From: asibross

Hey @wilkinsona - it turns out we have a plugin nebula-resolution-rules which tries to resolve all of the configurations it finds without considering whether the configuration itself is resolvable. We are going to fix it in the plugin by explicitly excluding archive and bootArchive configuration.

I still think it makes sense to add attributes for the bootArchives configuration in case there are other rough plugins.

In any case, thanks for looking into this.

Comment From: wilkinsona

Thanks for the follow-up, @asibross.

The Gradle team advised against adding attributes to bootArchives:

Choosing the proper values here is tricky though, since these values are meant to be set in the context of dependency resolution — and it looks like the the bootArchives configuration isn’t meant to participate in dependency resolution at all.

I think we should try to deprecate and eventually remove bootArchives instead. I have opened https://github.com/spring-projects/spring-boot/issues/34963 for that. In the meantime I would prefer not to abuse the attributes unless it's absolutely necessary so I'm going to close this issue for now at least. We can reconsider if others have problems that can't be easily worked around.