Skip to content

Dependency resolution fails with Gradle 5.3.x to 5.6.x #19783

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

Closed
denisw opened this issue Jan 17, 2020 · 11 comments
Closed

Dependency resolution fails with Gradle 5.3.x to 5.6.x #19783

denisw opened this issue Jan 17, 2020 · 11 comments
Labels
type: regression A regression from a previous release
Milestone

Comments

@denisw
Copy link
Contributor

denisw commented Jan 17, 2020

I just tried to install v2.2.3 by updating the Gradle plugin:

plugins {
        id "org.springframework.boot" version "2.2.3.RELEASE" // was 2.2.2.RELEASE
}

However, when I try to build, I get the following dependency resolution error:

> Could not resolve all files for configuration ':example:detachedConfiguration17'.
   > Could not resolve org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3.
     Required by:
         project :example
      > Cannot choose between the following variants of org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3:
          - enforcedRuntimeElements
          - runtimeElements
        All of them match the consumer attributes:
          - Variant 'enforcedRuntimeElements' capability org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3:
              - Unmatched attributes:
                  - Found org.gradle.category 'enforced-platform' but wasn't required.
                  - Found org.gradle.status 'release' but wasn't required.
                  - Found org.gradle.usage 'java-runtime' but wasn't required.
          - Variant 'runtimeElements' capability org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3:
              - Unmatched attributes:
                  - Found org.gradle.category 'platform' but wasn't required.
                  - Found org.gradle.status 'release' but wasn't required.
                  - Found org.gradle.usage 'java-runtime' but wasn't required.

This is with a pure-Java project (not using Kotlin).

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 17, 2020
@denisw
Copy link
Contributor Author

denisw commented Jan 17, 2020

I fixed the problem by upgrading from Gradle v5.6.4 to v6.0.1. I guess either the problem should be worked around or the minimum required Gradle version should be bumped to Gradle v6.

@xuyu
Copy link

xuyu commented Jan 17, 2020

+1 with Gradle v5.6.4

@wilkinsona
Copy link
Member

wilkinsona commented Jan 17, 2020

Thanks for letting us know and sorry for the inconvenience.

The problem’s caused by spring-boot-dependencies upgrading from Kotlin Coroutines 1.3.2 to 1.3.3. Unfortunately this affects pure-Java projects as the Kotlin Coroutines bom is imported in the spring-boot-dependencies bom.

Kotlin Coroutines started publishing Gradle Module Metadata in 1.3.3. They’re building with Gradle 5.6.x and, unfortunately, the metadata it produced breaks resolution of the pom by the dependency management plugin. This is due to a bug in the metadata. Gradle 6 works around this bug on the consuming side by ignored metadata published with Gradle 5. It also corrects the metadata on the producing side. As you have seen, this means that the problem can be avoided by upgrading your build to Gradle 6. It could also be fixed by the Kotlin team doing the same and publishing a new release with updated metadata.

You should be able to work around the problem by overriding the version of the Kotlin Coroutines bom that is imported by Boot’s dependency management:

ext['kotlin-coroutines.version']='1.3.2'

This should allow you to use Gradle 4.x or 5.x.

I’m not yet sure what the way forward should be for Boot 2.2.x. We do not want to require Gradle 6 until Boot 2.4. We also do not want to get stuck on Kotlin Coroutines 1.3.2 in the long term. We may be able to work around the problem in the dependency management plugin or we may be able to get the Kotlin team to make a change to either stop publishing the metadata until they upgrade to Gradle 6. In the meantime, please try the workaround above and let us know if the problem persists.

@wilkinsona
Copy link
Member

The recently released 1.0.9 of the Dependency Management Plugin contains a workaround and Spring Boot has been upgraded to use that version in 7693d33.

Bert-R added a commit to yonadev/yona-server that referenced this issue Jan 20, 2020
The issue that triggered the upgrade to Gradle 6.1 (spring-projects/spring-boot#19783) is resolved in this version, so strictly speaking, we can stick with the previous version of Gradle (and the Docker plug-in), but everything works, so let's move along.
@amarkevich
Copy link

there is no issue using BOM dependency resolution:

dependencies {
implementation platform("org.springframework.boot:spring-boot-dependencies:${springBootVersion}")

@wilkinsona
Copy link
Member

@amarkevich That’s using Gradle’s platform support rather than the dependency management plugin. Only the latter is affected by the pom resolution problem in Gradle 5.3-5.6 when the pom is accompanied by Gradle Module Metadata.

@krishnageddam
Copy link

krishnageddam commented Jan 23, 2020

This problem still exists in my project . I upgrade the Gradle to latest version(6.1) and my Kotlin version is 1.3.6
SpringBoot version is 2.1.6

Error
Execution failed for task ':compileJava'.

Could not resolve all files for configuration ':detachedConfiguration66'.
Could not resolve org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3.
Required by:
project :
> Cannot choose between the following variants of org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3:
- enforcedRuntimeElements
- runtimeElements
All of them match the consumer attributes:
- Variant 'enforcedRuntimeElements' capability org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3:
- Unmatched attributes:
- Found org.gradle.category 'enforced-platform' but wasn't required.
- Found org.gradle.status 'release' but wasn't required.
- Found org.gradle.usage 'java-runtime' but wasn't required.
- Variant 'runtimeElements' capability org.jetbrains.kotlinx:kotlinx-coroutines-bom:1.3.3:
- Unmatched attributes:
- Found org.gradle.category 'platform' but wasn't required.
- Found org.gradle.status 'release' but wasn't required.
- Found org.gradle.usage 'java-runtime' but wasn't required.

@snicoll
Copy link
Member

snicoll commented Jan 23, 2020

@krishnageddam Spring Boot 2.1 does not have dependency management for coroutines. As indicated above, if you chose to use coroutines with that version of Spring Boot, upgrade to version 1.0.9 of the Dependency Management Plugin. Alternatively, upgrading to Spring Boot 2.2.4 will work out of the box.

@krishnageddam
Copy link

Thank you a lot .

@jndietz
Copy link

jndietz commented Feb 10, 2020

Experiencing this in my projects as well.

Gradle: 5.6.4
Spring Boot: 2.2.4.RELEASE
Dependency Management: 1.0.9.RELEASE
Cloud Version: Hoxton.SR1

@snicoll
Copy link
Member

snicoll commented Feb 10, 2020

@jndietz this issue is closed. If you believe you've found an issue with Spring Boot (remove the Spring Cloud bits first), please create a separate issue with a sample we can run ourselves (a zip or a link to a github repo).

Bert-R added a commit to yonadev/yona-server that referenced this issue Feb 10, 2020
* YD-659 Ran Spring Hateoas migration script

And made some manual changes. Many other changes are needed to get to Spring Hateaos 1.0.1

* YD-659 Use SimpleRepresentationModelAssembler

ControllerBase now requires the interface RepresentationModelAssembler rather than the implementation class RepresentationModelAssemblerSupport.

* YD-659 Everything compiles again

Using a snapshot build of Spring Hateoas 1.1.0.M1

* YD-659 Fixed the unit tests

We now use the Mockito version that comes with the Spring Boot version. Upgraded the equalsverifier to see whether it fixed our issue (it didn't). Then fixed the GoalDtoTest and removed a deprecation warning from DeviceServiceTest.java

* YD-659 Made the integration tests work again

Along with this standardized naming and type for link relations. They are all defined as LinkRelation XXX_REL. The message handlers need the name as well (for a switch statement). In that case, the string is defined as XXX_REL_NAME.

* YD-659 Removed workaround for Spring Hateoas issue

Issue spring-projects/spring-hateoas#703 is resolved in 1.1.0.M1, so removed the workaround. To verify this, the test password now includes a character that needs to be encoded, and the integration test verifies that this encoding is done properly. It is not strictly necessary to do this, as we nowadays only generate temp passwords that do not need encoding. However, the test was extended as the web service layer should not depend on the password strategy.

* YD-659 Switched to Spring Hateoas 1.0.2

This release includes spring-projects/spring-hateoas#1126 and spring-projects/spring-hateoas#1130, so no need to wait for 1.1.0.

* YD-659 Upgrade to Spring Boot 2.2.2

This includes Spring Hateoas 1.0.2

* YD-659 Removed direct spring-hateoas dependency

It comes along with the starter already and the version number was wrong.

* YD-659 Addressed SonarQube feedback

* Used a method reference instead of a call
* Removed unused import

* YD-659 Upgraded to Spring Boot 2.2.3

This caused an issue that is resolved in Gradle 6.1, so upgraded to that. That however requires a newer version of the Gradle Docker plugin, so upgraded that to the latest version (6.1.2)

* YD-659 Addressed review comments

* Corrected comment in SecurityProperties (was accidentally updated by Spring HATEOAS upgrade script)
* Corrected comment in CreateUserOnBuddyRequestTest.Hacking attempt: Try to get a user created on buddy request with normal Yona password header()
* Replaced ActivityControllerBase.PREV_REL and ActivityControllerBase.NEXT_REL with IanaLinkRelations.PREV and IanaLinkRelations.NEXT respectively.
* Replaced JsonRootLinkRelationProvider.EDIT_REL with IanaLinkRelations.EDIT

* YD-659 Upgraded to Spring Boot 2.2.4

The issue that triggered the upgrade to Gradle 6.1 (spring-projects/spring-boot#19783) is resolved in this version, so strictly speaking, we can stick with the previous version of Gradle (and the Docker plug-in), but everything works, so let's move along.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression A regression from a previous release
Projects
None yet
Development

No branches or pull requests

9 participants