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
On this weeks JUG event I learned that Gradle has an equivalent to Mavens dependency management, which remind me to last week, where @nipafx was replacing some duplicate version definitions with versions variables.
With this we could replace our version variables with this catalog so that all our dependencies in the build file would look like the current JUnit dependencies which versions are defined in the correlated BOM. example:
implementation(group = "org.junit.jupiter", name = "junit-jupiter-api")
implementation(group = "org.junit.jupiter", name = "junit-jupiter-params")
implementation(group = "org.junit.platform", name = "junit-platform-launcher")
But I think we need to discuss if we want to move the version definition away from the build file into the settings, esp. as the JUnit BOM version comes from the build pipeline. On the other hand we would replace the current mixture of version strings (for those dependencies we use multiple times) and hard coded versions, e.g. this section
testImplementation(group = "org.assertj", name = "assertj-core", version = assertjVersion)
testImplementation(group = "org.mockito", name = "mockito-core", version = "4.11.0")
testImplementation(group = "com.google.jimfs", name = "jimfs", version = jimfsVersion)
testImplementation(group = "nl.jqno.equalsverifier", name = "equalsverifier", version = "3.14.1")
The text was updated successfully, but these errors were encountered:
On this weeks JUG event I learned that Gradle has an equivalent to Mavens dependency management, which remind me to last week, where @nipafx was replacing some duplicate version definitions with versions variables.
In Gradle you can do the following (example taken from the Gradle version catalog documentation):
Defining a version catalog for libraries in
settings.gradle(.kts)
and then just a a
lib(xx)
call in the build file:With this we could replace our version variables with this catalog so that all our dependencies in the build file would look like the current JUnit dependencies which versions are defined in the correlated BOM. example:
But I think we need to discuss if we want to move the version definition away from the build file into the settings, esp. as the JUnit BOM version comes from the build pipeline. On the other hand we would replace the current mixture of version strings (for those dependencies we use multiple times) and hard coded versions, e.g. this section
The text was updated successfully, but these errors were encountered: