-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Regression in 5.5 when using dependency constraints for non-jar dependencies without a POM #10948
Comments
I have some cleaned up debug logs that pretty clearly show the regression. If you look at the diff, on 5.4.1 we use the correct
|
@pkoenig10 thanks for the detailed report and for taking the time to narrow this down. Unfortunately, I cannot reproduce it. Running your minimal build does not produce the issue for me with any of the indicated versions. It's very suspicious. Did you run the build in isolation or is there maybe anything else in your settings that might cause a problem? Can you check again and maybe run your minimal build with an isolated Gradle user home ( |
I am able to reproduce this issue with an isolated Gradle user home. I was also able to reproduce this issue using the official Gradle docker image. I ran the following command:
With the following The build scan for this build can be found here: Note that I was also able to reproduce this issue using all of the following official Gradle docker images:
|
I was able to get a successful using Gradle 5.4.1 build by running the same command with the same
And here's the build scan for that build: |
This test reproduces #10948 and other variations of it.
This test reproduces #10948 and other variations of it.
@pkoenig10 thanks again for taking the time and the hint of using the docker images. Running in a clean container exposed the issue. Which, as it turned out, is a more involved issue with discovering a component without metadata in a repository - see #10996 for details. The issue was hidden if an earlier version of Gradle already discovered the component. In that case, we do not check the repository again as we already know that the component exists there. The fix #10996 will be in Gradle 6.0. Feel free to try the next
We are considering another patch release for 5.6 and will possibly include this fix. I'll keep this issue open until that is decided/done. |
This test reproduces #10948 and other variations of it.
This test reproduces #10948 and other variations of it.
Closing as this was merged for 6.0 and 5.6.3 |
Expected Behavior
Using dependency constraints to resolve a non-jar dependency without a POM file should succeed.
Current Behavior
Using dependency constraints to resolve a non-jar dependency without a POM file fails because Gradle expected to find either a POM file or a jar file.
Context
This works on version 5.4.1. It stopped working in version 5.5-rc-1 and continues to not work up through version 5.6.2.
I was able to narrow down the regression further by testing against snapshots. This works in 5.5-20190515000032+0000 but does not work in 5.5-20190515115345+0000.
We are using Gradle to resolve and download dependencies that were not published with Gradle/Maven. More specifically, we are using Gradle to resolve and download a archive with static files that we want to include the jar we publish.
Steps to Reproduce
Here is a minimal
build.gradle
file necessary to reproduce the issue:resolvePomWithVersion
,resolvePomWithConstraint
, andresolveNoPomWithVersion
succeed on all versions.resolveNoPomWithConstraint
succeeds on version 5.4.1 and fails on versions 5.5-rc-1 and later with the following error:This fails even if I add
transitive = false
to the dependency.Be sure to run these tasks with
--refresh-dependencies
to ignore cached dependencies downloaded when using Gradle versions without the bug.Your Environment
I don't think there's anything specific in my environment that would affect this issue. But I'm happy to provide build scans or more info if you are unable to reproduce the issue and/or would find them useful.
The text was updated successfully, but these errors were encountered: