-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade Gradle to 7.4 & AGP to 7.1.1 (& Disable Jetifier & Dependency Removal) #18
Conversation
The 'com.dipien.byebyejetifier' plugin was used to determine whether Jetifier can be disable for this project. After configuring 'Bye Bye Jetifier' and running the below command: ./gradlew canISayByeByeJetifier -Pandroid.enableJetifier=false The output was clear, Jetifier can be now safely disabled for this project: > Task :canISayByeByeJetifier ========================================= Project: : ========================================= * No legacy android support usages found ===================================================== ... * No dependencies with legacy android support usages! ... ===================================================== ... ... =============================== ... You can say Bye Bye Jetifier. * ... ===============================
The 'com.dipien.byebyejetifier' plugin was used to determine whether Jetifier can be disable for this project. After configuring 'Bye Bye Jetifier' and running the below command: ./gradlew canISayByeByeJetifier -Pandroid.enableJetifier=false The output was clear, Jetifier can be now safely disabled for this project: > Task :canISayByeByeJetifier ========================================= Project: : ========================================= * No legacy android support usages found ===================================================== ... * No dependencies with legacy android support usages! ... ===================================================== ... ... =============================== ... You can say Bye Bye Jetifier. * ... ===============================
Lint error message: "It looks like you are trying to substitute a version variable, but using single quotes ('). For Groovy string interpolation you must use double quotes ("). To insert the value of a variable, you can use ${variable} inside a string literal, but only if you are using double quotes!"
👋 @mchowning ! Can you verify that this change I did here, which removes this incorrect PS: I did that because otherwise Lint errors for both, this repo and the |
@@ -55,7 +55,6 @@ dependencies { | |||
implementation('com.google.android.exoplayer:extension-okhttp:2.13.3') { | |||
exclude group: 'com.squareup.okhttp3', module: 'okhttp' | |||
} | |||
implementation 'com.squareup.okhttp3:okhttp:${OKHTTP_VERSION}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would the better fix here be to just change this to double-quotes? We could also do a PR to push this fix upstream, we're not the first to notice it: TheWidlarzGroup@3dc607c.
Just for reference: here is the PR adding this line to react-native-video: TheWidlarzGroup#2340
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 @mchowning !
Thanks for the response! 🥇
Would the better fix here be to just change this to double-quotes?
I actually tried that but it doesn't work as the OKHTTP_VERSION
is not available, it only resides within the RN note module
. Thus, the build failed when I tried.
My question is if we actually need this dependency, since we are able to build even without it. 🤔
We could also do a PR to push this fix upstream, we're not the first to notice it: TheWidlarzGroup@3dc607c.
We can try doing that, yes. 👍
Just for reference: here is the PR adding this line to react-native-video: TheWidlarzGroup#2340
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually tried that but it doesn't work as the OKHTTP_VERSION is not available, it only resides within the RN note module. Thus, the build failed when I tried.
Ah good point. We could always wrap this in a project.hasProperty(...)
, but keeping it simple here by just removing it also seems fine since we obviously haven't needed it.
If you want to go with the "removal" approach you have here, I'm curious if you have any thoughts about possibly commenting out this line and adding a comment describing why it is being commented out. We generally try to keep these forks as close to the source as possible, and I'm thinking it might be hard for someone to backtrack and figure out why we removed this line when the inevitable conflict on this line arises in the future. I don't feel strongly, I'm more just thinking out loud, so let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It builds without this dependency because okhttp
is a transitive dependency of com.facebook.fresco:imagepipeline
. If this project is using okhttp
directly, we should keep it and use the version we want. If the project is not using it directly, it should be fine to remove it as whichever dependency needs it should also have it in its pom file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 @mchowning @oguzkocer !
Thank you so much for your input! 🙏
Ah good point. We could always wrap this in a project.hasProperty(...), but keeping it simple here by just removing it also seems fine since we obviously haven't needed it.
This is a good idea. 👍
If you want to go with the "removal" approach you have here, I'm curious if you have any thoughts about possibly commenting out this line and adding a comment describing why it is being commented out. We generally try to keep these forks as close to the source as possible, and I'm thinking it might be hard for someone to backtrack and figure out why we removed this line when the inevitable conflict on this line arises in the future. I don't feel strongly, I'm more just thinking out loud, so let me know what you think.
Yes, this is a good argument, on keeping the forks as close to the source as possible, I agree. 👍
It builds without this dependency because okhttp is a transitive dependency of com.facebook.fresco:imagepipeline.
Yes, actually after running ./gradlew dependencies
and checking the before and after result, com.squareup.okhttp3:okhttp-urlconnection
is also using okhttp
as a transitive dependency, as the whole androidx.appcompat:appcompat
dependency itself.
I also did a quick analysis, using ./gradlew dependencies
, a before and after diff for the removal of the explicit 'com.squareup.okhttp3:okhttp:${OKHTTP_VERSION}'
dependency and the only diff I found are the below line, which is found twice on the top level and the com.facebook.react:react-native:0.66.2
tree:
+--- com.squareup.okhttp3:okhttp:${OKHTTP_VERSION} -> 4.9.1 (*)
This makes me think that:
- The
${OKHTTP_VERSION}
is being hardcoded and doesn't change to theOKHTTP_VERSION=3.12.12
as defined by thegradle.properties
of theReactAndroid
project. Thus, it seems to me that Gradle just ignores while building and then Lint produces theIncorrect Interpolation
error. - With or without this incorrectly defined dependency, due to the
Incorrect Interpolation
error, the end result of building the project is the same. However, this is solely based on building and linting this project individually. If, for some reason, unknown to me due to my lack of React Native experience, when this project is build and used in combination with theReactAndroid
project, it might actually do some code-generation magic to substitute thisOKHTTP_VERSION
version with the actual version to produce the final result. Thus, then I would no longer feel comfortable removing this dependency.
If this project is using okhttp directly, we should keep it and use the version we want. If the project is not using it directly, it should be fine to remove it as whichever dependency needs it should also have it in its pom file.
Good thinking. 🥇
From what I am seeing this project is using a couple of okhttp3
imports within the DataSourceUtil
, which makes me think, just to be on the safe side, since I am not having much React Native experience, to keep this dependency and suppress this Incorrect Interpolation
Lint error to avoid future such discussions and have Lint success no matter. Wdyt? 🤔
Commit here: 4fa6833
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I am seeing this project is using a couple of okhttp3 imports within the DataSourceUtil, which makes me think, just to be on the safe side, since I am not having much React Native experience, to keep this dependency and suppress this Incorrect Interpolation Lint error to avoid future such discussions and have Lint success no matter. Wdyt?
That doesn't quite feel right to me since we're suppressing a lint warning that is highlighting the fact that this line of code doesn't actually do anything. I don't feel super-strongly, but in light of @oguzkocer 's comment noting that the build only succeeds because okhttp is a transitive dependency (thanks for pointing that out btw), I'd lean toward fixing this with the project.hasProperty(...)
wrapper and then switching to using double quotes. That way we can set that variable and actually use it if we want to, and it will be more informative to any developer that bumps into this issue in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 @mchowning !
...I'd lean toward fixing this with the project.hasProperty(...) wrapper and then switching to using double quotes.
Yes, I think this is better. The only reason I didn't proceed with this change is because you mentioned that we generally try to keep these forks as close to the source as possible and I wasn't sure If I should proceed with this change.
Please expect me applying this change today. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now done: b1bff8b
For more info about that read full discussion here: https://github.com/ /pull/18#discussion_r814883725
Since we removed the source code for these projects from PS: Eventually, we might upgrade |
This PR is part of Upgrade Gradle to 7.4 & AGP to 7.1.1 (& Disable Jetifier) PR. There are
13
libraries that are upgraded toGradle 7.4
&AGP 7.1.1
(&Disable Jetifier
).All those PRs follow the general outline below:
Gradle
version upgraded to7.3.3
with the./gradlew wrapper --gradle-version=7.3.3 --distribution-type=all
command.AGP
version upgrade to7.0.4
(seeandroid/settings.gradle.kts
change).Gradle 7.4
&AGP 7.1.1
.android-exoplayer
andandroid
projects.android/gradle.properties
change).5.2.0-wp-3
(seepackage.json
).5.2.0-wp-3
(seereact-native-video-5.2.0-wp-3.tgz
).This PR also included the following changes:
openjdk11
(seejitpack.yml
change).com.squareup.okhttp3:okhttp
dependency declaration (seeandroid-exoplayer/build.gradle
change).To test - Now
These changes can be tested as part of the gutenberg PR which is updated to use the temporarily non-tagged node module project dependencies generated with these changes.
To test - Later ⚙️
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.
FYI: It's best to leave the testing step to the gutenberg PR review since even if these PRs are merged, they won't impact anything until the package.json file is updated. Worst case scenario, a follow up PR will get opened to fix any issues that are found during testing.
Follow up
Once these PRs are merged in, a new tag will get created for each library and the package.json file will be again updated accordingly.