This repository has been archived by the owner on Jul 27, 2023. It is now read-only.
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 part of Gradle 7 upgrade for react-native libraries for Gutenberg. There are 13 libraries that are upgraded to Gradle 7 and they follow the general outline below:
./gradlew wrapper --gradle-version=7.1.1 --distribution-type=all
command. There were a few cases wheregradlew
file was missing or wasn't executable, and these were also addressed as part of this change.settings.gradle.kts
file by utilizing Plugin DSL. Since only one settings file is executed per build, except for composite builds, this allows us to change the plugin versions from the root project. For example, all these projects are added toreact-native-bridge
as a project dependency and now thatreact-native-bridge
itself uses Plugin DSL, it can set the Android Gradle plugin & Kotlin plugin version without making changes to these libraries. This should make our lives easier when it comes to upgrading to new versions of Android Gradle plugin.android
extension by removing the fancyminSdk
,targetSdk
etc setting. If these need to be updated I think they should be done directly as a PR and the fancy code is just making things harder to follow. It's also perfectly fine for a library to be on a lower version if it works fine with it. I think this setting is much more important for applications.repositories
&dependencies
sections of the build file. I am still not super happy with this one, but it'll need to be improved again at a later time, possibly with the new Gradle 7 dependency management features. Most of them are exactly the same, with a few exceptions where it was necessary.gradle.properties
. I went for a simple version which should work pretty much all the time.maven-publish
plugin and sets up thepublishing
block. This allows Jitpack to publish the artifacts and with this update we are actually only one step away from publishing them to S3 🤷jitpack.yml
where it's not necessary, or simplifies it greatly by only including what's necessary - such as switching to a different directory because Jitpack can't find the project.There might be some minor changes for a few projects, but hopefully they'll be self-explanatory. Also the first few PRs I opened may be a little different, but it seems to work and I think we can live with that inconsistency. There is just too many PRs to keep everything straight in my head :(
To test
These changes can be tested as part of the gutenberg-mobile PR or WordPress-Android PR which is updated to use the bundle generated with these changes. Having said that, I think it's best to leave the testing step to the gutenberg PR review since even if we merge these PRs in, it won't impact anything until we update the
package.json
file that adds these libraries. So, worst case scenario, we just open a follow up PR to fix any issues we find during testing. It's up to the reviewer to decide how to go about testing.Follow up
Once these PRs are merged in, we'll create a new tag for each library and update the
package.json
file again.