Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a continuation of #3232 and supersedes that one.
Soon, hopefully, Dependabot will be able to support version catalogs: dependabot/dependabot-core#6249
That's why the
libs.versions.toml
file is still kept, despite introducing a bit of duality in the build setup.Below is @simonbasle's original description:
This PR replaces Renovate with Dependabot.
Despite being less configurable, Dependabot can target a non-default branch.
One limitation is that Dependabot currently doesn't process version catalogs, even in the standard format of gradle/libs.versions.toml.
It should however be able to process version strings imported from a .gradle file as long as the filename contains dependencies` (see source).
So unfortunately this means rolling back version catalogs, at lest partially.
The version declarations broadly go into 4 categories:
While (4) can and should be managed by Dependabot, the first three categories cannot or shouldn't.
In this PR I chose to keep (1/2/3) in the libs.versions.toml version catalog and split out versions from (4) into a new gradle/dependencies.gradle file to be imported.
That file would thus be understood, monitored and updated by Dependabot only, while we continue to make manual edits to gradle/libs.versions.toml (and root gradle.properties).
Drawbacks
The plugins won't be auto-updated anymore and will need manual monitoring and updates.
Alternatives
This is more a question of style but in the current state, we reintroduce the artifact coordinates in each build.gradle (eg. implementation "group:my-artifact:$myArtifactVersion").
I've found one blog post that uses a different style where the whole coordinates are defined inside the dependencies.gradle file in a dictionnary:
// in
gradle/dependecies.gradle
:libs = {
myArtifact : "group:my-artifact:$myArtifactVersion"
}
// in individual
build.gradle
filesdependencies {
implementation libs.myArtifact
}
See blog post.
This could be considered as a further improvement.