Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle Plugin: Configurations should add Gradle.USAGE attribute to eg kover #678

Closed
hfhbd opened this issue Aug 26, 2024 · 2 comments · Fixed by #680
Closed

Gradle Plugin: Configurations should add Gradle.USAGE attribute to eg kover #678

hfhbd opened this issue Aug 26, 2024 · 2 comments · Fixed by #680
Assignees
Labels
Bug Bug issue type S: ready for release Status: merged in the main branch

Comments

@hfhbd
Copy link

hfhbd commented Aug 26, 2024

Describe the bug
All outgoing configurations of Kover don't set the Gradle.USAGE attribute. Without this attribute, Gradles attribute matching algorithm accepts kovers artifacts even if you (as Gradle plugin author) want to resolve artifacts with other attributes.

Use-case: I applied the kover plugin using the settings plugin and have a custom Gradle plugin that wants to resolve a configuration with USAGE but there is no configuration with matching USAGE so Gradle should fail. But Gradles attribute matching algorithm (wrongly) choose a consumable configuration as long as there are no conflicting attributes, and ignores requires/provided attributes. So without USAGE attribute, Gradle simply choose kover artifacts. The Gradle USAGE attribute is the most relevant attribute (Indicates main purpose of variant) and Gradle authors should set it.

Errors
n/a

Expected behavior
A Gradle variant error because I fetch Gradle.USAGE="foo" and kover provides Gradle.USAGE="kover"

Reproducer
n/a

Reports
n/a

Environment

  • Kover Gradle Plugin version: 0.8.3
  • Gradle version: 8.10
  • Kotlin project type: Kotlin/JVM 2.0.20
  • Coverage Toolset: Kover
  • Other context important for this bug: n/a
@hfhbd hfhbd added Bug Bug issue type S: untriaged Status: issue reported but unprocessed labels Aug 26, 2024
@shanshin shanshin added S: in progress Status: implementing or design in process and removed S: untriaged Status: issue reported but unprocessed labels Aug 26, 2024
@shanshin
Copy link
Collaborator

Thanks for the hint!
Indeed, it is better to specify this attribute

@shanshin shanshin reopened this Aug 29, 2024
@shanshin shanshin added S: ready for release Status: merged in the main branch and removed S: in progress Status: implementing or design in process labels Aug 29, 2024
@shanshin
Copy link
Collaborator

shanshin commented Sep 3, 2024

Implemented in 0.9.0-RC

@shanshin shanshin closed this as completed Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Bug issue type S: ready for release Status: merged in the main branch
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants