[EXTERNAL] Migrate to Gradle version catalog #1033
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Next we'll move all dependencies in
Only use versions where we actually have multiple versions. Next commits will be updating build.gradle with the change in notation
We set all plugins in the base gradle file but we only apply the one's we're actually using in the root build.gradle. We can then use the aliases in other build.gradle and actually apply them where they are actually used. The pluginManagement block is set the repositories from which we'll fetch the plugin dependencies
Currently it is not possible to specify plugins in an init script: https://docs.gradle.org/current/userguide/plugins.html#sec:build_scripts_only This is unfortunate but I think this is still worth doing. We'll apply the plugins to each gradle file in the next commit
Same as all the previous steps just confined to the MagicWeather sample
mikescamell
changed the title
|
Thanks for opening this! We've decided we are going to tackle this. If you don't mind I am going to merge this PR into a branch and I will make some changes into it, like rebasing it and update to the latest versions. Your name will still appear as contributor in the changelog. |
vegaro
changed the base branch from
main
to
cesar/sdk-3179-migrate-to-gradle-version-catalog
vegaro
merged commit 1b6eb17
into
RevenueCat:cesar/sdk-3179-migrate-to-gradle-version-catalog
vegaro
changed the title
vegaro
pushed a commit
that referenced
this pull request
Jun 12, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Checklist
purchases-iosand hybridsMotivation
This pull request aims to improve the management of dependencies and plugins in the codebase by migrating them to a
.tomlfile and utilizing Gradle version catalogs. This standardizes the dependencies and plugins across the project and facilitates automated dependency updates through tools like Dependabot or Renovate. I have prior experience using Renovate and find it highly useful, but I see Dependabot enabled in the project and it should also support thisDescription
In this pull request, I have relocated all dependencies and plugins to the
.tomlfile. Additionally, I have updated each module accordingly. To ensure independent accessibility, I have also created a separate.tomlfile for the MagicWeather app.Versions have only been added to the
versionsblock when used across multiple dependencies.However, there is one limitation: the plugins block cannot be used in a Gradle init script. As a result, all plugin declarations must be moved to individual modules. Fortunately, this limitation is expected to be removed in the future. On the positive side, this approach allows us to include only the necessary plugins for each module, rather than applying all plugins universally (e.g., the Parcelize plugin may not be needed in every module).
I have a question regarding the stdlib declaration. Is it necessary for us to include it explicitly, or can we rely on the Kotlin plugin to handle it automatically?
It might make sense to merge this after the next release, so there's plenty of time to notice any obvious issues.