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
When a user has configured a dependency with a dynamic version (e.g. +, or latest.release), the plugin will override that version if the dependency is covered by the project's dependency management. Arguably, trying to use dependency management and dynamic versions at the same time doesn't make much sense. The current approach is one way to resolve the conflicting requirements, it might also be reasonable to:
Ignore dependencies with dynamic versions (and perhaps log a warning)
Trigger a build failure due to the conflicting requirements
A further consideration here is the Gradle versions plugin, particularly the problem described in ben-manes/gradle-versions-plugin#97. It copies a configuration and changes the dependencies to use + as the version so that it can figure out the latest version. The dependency management plugin's resolution strategy then replaces the + with whatever's specified by dependency management so the versions plugin returns an inaccurate result.
My current thinking is for the plugin to offer different modes:
Silently ignore dependencies with dynamic versions
Ignore dependencies with dynamic versions and log a warning
Apply dependency management to dependencies with dynamic versions
Fail if a dependency with a dynamic version is covered by dependency management
The current behaviour is 3. I am tempted to change the default to 1.
The text was updated successfully, but these errors were encountered:
When a user has configured a dependency with a dynamic version (e.g.
+
, orlatest.release
), the plugin will override that version if the dependency is covered by the project's dependency management. Arguably, trying to use dependency management and dynamic versions at the same time doesn't make much sense. The current approach is one way to resolve the conflicting requirements, it might also be reasonable to:A further consideration here is the Gradle versions plugin, particularly the problem described in ben-manes/gradle-versions-plugin#97. It copies a configuration and changes the dependencies to use
+
as the version so that it can figure out the latest version. The dependency management plugin's resolution strategy then replaces the+
with whatever's specified by dependency management so the versions plugin returns an inaccurate result.My current thinking is for the plugin to offer different modes:
The current behaviour is 3. I am tempted to change the default to 1.
The text was updated successfully, but these errors were encountered: