Deprecate using legacy Usage attribute values #35238
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ad5e8b4 to
70c0d41
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
70c0d41 to
d219dac
Compare
|
The following builds have failed: |
These legacy attribute values were deprecated in Gradle 5.6, with the intention to add deprecation warnings in 6.0 Better late than never, so we're adding the deprecations now. Trying to use any of these legacy Usage values in build logic will result in a deprecation warning, as the mutable attribute container emits a warning if it encounters a legacy value. Additionally, we specially handle legacy Usage attributes in published GMM parsing, as published GMM with these attributes must always be handled in a backwards compatible manner. In all other cases, traces of these legacy attributes have been removed from the core attribute container implementation. Attribute containers should be agnostic about the attributes they hold, and should not treat certain attributes specially compared to others
d219dac to
2230307
Compare
|
@bot-gradle test this |
This comment has been minimized.
This comment has been minimized.
|
The following builds have failed: |
lkasso
reviewed
Oct 10, 2025
| Use link:{javadocPath}/org/gradle/api/tasks/wrapper/Wrapper.DistributionType.html#values()[`Wrapper.DistributionType.values()`] to obtain the available distribution types instead. | ||
|
|
||
| [[deprecate_legacy_usage_values]] | ||
| ==== Deprecated legacy Usage attribute values |
There was a problem hiding this comment.
Suggested change
| ==== Deprecated legacy Usage attribute values | |
| ==== Deprecated legacy `Usage` attribute values |
| [[deprecate_legacy_usage_values]] | ||
| ==== Deprecated legacy Usage attribute values | ||
|
|
||
| Since Gradle 5.6, the link:{javadocPath}/org/gradle/api/attributes/Usage.html[`Usage`] attribute was split into a separate link:{javadocPath}/org/gradle/api/attributes/LibraryElements.html[`LibraryElements`] attribute. |
There was a problem hiding this comment.
Suggested change
| Since Gradle 5.6, the link:{javadocPath}/org/gradle/api/attributes/Usage.html[`Usage`] attribute was split into a separate link:{javadocPath}/org/gradle/api/attributes/LibraryElements.html[`LibraryElements`] attribute. | |
| Since Gradle 5.6, the link:{javadocPath}/org/gradle/api/attributes/Usage.html[`Usage`] attribute has been split into a separate link:{javadocPath}/org/gradle/api/attributes/LibraryElements.html[`LibraryElements`] attribute. |
| ==== Deprecated legacy Usage attribute values | ||
|
|
||
| Since Gradle 5.6, the link:{javadocPath}/org/gradle/api/attributes/Usage.html[`Usage`] attribute was split into a separate link:{javadocPath}/org/gradle/api/attributes/LibraryElements.html[`LibraryElements`] attribute. | ||
| In the JVM ecosystem, `Usage` controls whether a variant is intended for compilation or runtime, while `LibraryElements` controls the format of the artifact (for example, JAR or classes directory). |
There was a problem hiding this comment.
Suggested change
| In the JVM ecosystem, `Usage` controls whether a variant is intended for compilation or runtime, while `LibraryElements` controls the format of the artifact (for example, JAR or classes directory). | |
| In the JVM ecosystem, `Usage` indicates whether a variant is intended for compilation or runtime, while `LibraryElements` specifies the format of the artifact (for example, a JAR file or a classes directory). |
| Since Gradle 5.6, the link:{javadocPath}/org/gradle/api/attributes/Usage.html[`Usage`] attribute was split into a separate link:{javadocPath}/org/gradle/api/attributes/LibraryElements.html[`LibraryElements`] attribute. | ||
| In the JVM ecosystem, `Usage` controls whether a variant is intended for compilation or runtime, while `LibraryElements` controls the format of the artifact (for example, JAR or classes directory). | ||
|
|
||
| In order to ease the migration, Gradle automatically maps legacy `Usage` values to the corresponding `Usage` and `LibraryElements` values: |
There was a problem hiding this comment.
Suggested change
| In order to ease the migration, Gradle automatically maps legacy `Usage` values to the corresponding `Usage` and `LibraryElements` values: | |
| To ease migration, Gradle has automatically mapped legacy `Usage` values to their corresponding `Usage` and `LibraryElements` pairs: |
| In the JVM ecosystem, `Usage` controls whether a variant is intended for compilation or runtime, while `LibraryElements` controls the format of the artifact (for example, JAR or classes directory). | ||
|
|
||
| In order to ease the migration, Gradle automatically maps legacy `Usage` values to the corresponding `Usage` and `LibraryElements` values: | ||
| |=== |
| | `java-runtime-resources` | `java-runtime` | `resources` | ||
| |=== | ||
|
|
||
| Starting in Gradle 10, Gradle will no longer perform this automatic mapping when a legacy `Usage` value is added to an `AttributeContainer` in build logic. |
There was a problem hiding this comment.
Suggested change
| Starting in Gradle 10, Gradle will no longer perform this automatic mapping when a legacy `Usage` value is added to an `AttributeContainer` in build logic. | |
| Starting with Gradle 10, this automatic mapping will no longer occur when legacy `Usage` values are added directly to an `AttributeContainer` in build logic. |
| |=== | ||
|
|
||
| Starting in Gradle 10, Gradle will no longer perform this automatic mapping when a legacy `Usage` value is added to an `AttributeContainer` in build logic. | ||
| In order to maintain backward compatibility with published metadata, Gradle will continue to translate legacy `Usage` values found in published Gradle Module Metadata. |
There was a problem hiding this comment.
Suggested change
| In order to maintain backward compatibility with published metadata, Gradle will continue to translate legacy `Usage` values found in published Gradle Module Metadata. | |
| To maintain backward compatibility, Gradle will continue translating legacy `Usage` values found in published Gradle Module Metadata. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These legacy attribute values were deprecated in Gradle 5.6, with the intention to add deprecation warnings in 6.0 Better late than never, so we're adding the deprecations now.
Trying to use any of these legacy Usage values in build logic will result in a deprecation warning, as the mutable attribute container emits a warning if it encounters a legacy value.
Additionally, we specially handle legacy Usage attributes in published GMM parsing, as published GMM with these attributes must always be handled in a backwards compatible manner.
In all other cases, traces of these legacy attributes have been removed from the core attribute container implementation. Attribute containers should be agnostic about the attributes they hold, and should not treat certain attributes specially compared to others
Reviewing cheatsheet
Before merging the PR, comments starting with