You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gradle has rich versioning so you can precisely specify versions. Included in that is the ability to specify rejected versions. The dependencyUpdate task should honor that and not suggest upgrading to versions that are rejected.
The text was updated successfully, but these errors were encountered:
This plugin performs a Configuration.copyRecursive() which should include those constraints. We then clear the dependencies, add them again but with a dynamic version, and as Gradle to resolve the versions. The most we do with constraints is allow them to be added as dependency queries for version upgrades, since as you said Gradle does not seem to enforce them. That use-case is for those who want to monitor their transitive dependency versions to keep them at the later baseline version.
For direct dependencies using a resolution strategy is common and we support that. The rejectVersionIf is a convenience for that.
Since we let Gradle do the resolution and perform a copy which should capture everything needed, it seems like you should ask the Gradle folks for clarity. We're simply using their api.
Gradle has rich versioning so you can precisely specify versions. Included in that is the ability to specify rejected versions. The dependencyUpdate task should honor that and not suggest upgrading to versions that are rejected.
The text was updated successfully, but these errors were encountered: