-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Revert file naming convention of .aar files to support fuzzy matching in build.gradle #112149
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
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
Could you take a look? @GaryQian |
1 similar comment
|
Could you take a look? @GaryQian |
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 PR seems to be missing some of the testing code removed in the original PR. Can you make sure this PR fully reverts the original PR? Tests that have comments "mimic the AGP plugin" seem to be missing. Things like the JDK bump can stay unless it causes incompatibility issues. This way we have more guarantees we are not introducing new bugs.
This PR is not intended to restore all the original PR1 changes This PR modifies the use of Maven-Publish to produce the correct AAR based on #101276 The Maven-Publish part of the code has been tested in #101276 This PR ensures that the code is correct without having to adjust the Maven-Publish-related test code |
The JDK version configuration in the CI file is not concerned, the latest flutter:master branch has been adjusted |
|
@GaryQian |
|
auto label is removed for flutter/flutter, pr: 112149, due to - Please get at least one approved review if you are already a member or two member reviews if you are not a member before re-applying this label. Reviewers: If you left a comment approving, please use the "approve" review action instead. |
|
auto label is removed for flutter/flutter, pr: 112149, due to Validations Fail. |
|
This still needs one more review to be landable! I've tagged a few others. |
There seems to be a need for approving comments LGTM |
|
Could you take a look? @christopherfujino @stuartmorgan @camsim99 |
|
Hope to deal with as soon as possible, affect the upgrade to the latest version! |
christopherfujino
left a comment
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.
RSLGTM
|
@JunhuaLin it looks like you have a test failure, however: |
|
auto label is removed for flutter/flutter, pr: 112149, due to - The status or check suite Windows tool_integration_tests_4_6 has failed. Please fix the issues identified (or deflake) before re-applying this label. |
This test failure has nothing to do with my PR |
|
Now,it‘s fine~ |
|
this change is going to cause add to app modules with multiple native dependencies to fail because of how gradle 7 does dependency resolution. Please test that case as well |
Can you give a detailed description demo?ORDoes this mean that there are multiple flutter plugin dependencies?this case:it's ok module dependency:build aar file tree:
pom dependencies:module_test pom file: flutterboost pom file: shared_preferences_android pom file: The dependencies in the POM are complete |
|
If you have your add to app project depending on another plugin with a native dependency (in your case, flutterboost depending on shared_preferences) via the pubspec, the dependencies in the POM uses the new classifier mechanism. For example., in my main add to app module, I use logging_to_logcat, which gets included like this: with the so, if you don't publish the artifacts in the new way with the classifiers, you will need to declare all Flutter dependencies with a native component manually in the gradle file of your native project. |
I created the following dependency structure:flutterboost depending on logging_to_logcat and okhttpflutterboost pubspec file: flutterboost gradle file: .flutter-plugins-dependencies file:Plugin dependent plugins also compile normally,look this:build aar file tree:module_test pom file:flutterboost pom file:logging_to_logcat pom file:This case is fine~ |
|
@AesSedai101 Can you confirm that @JunhuaLin 's explanation here resolves your concern? |
|
Yes, you should use rebase, but don't worry about the tree being broken, it is not your fault, it should become green again soon (it is green now). That check simply reflects the build status of tip-of-tree. |
Ok, I see~ Can my PR be merged in this case? We want to use the latest version as soon as possible |
That is not the behaviour I saw on my side, but it's possible that my environment is in a broken state |
I'm not sure I understand your situation. You can use my branch master version to verify your problem |
|
@AesSedai101 Ping on @JunhuaLin 's questions |
|
Can my PR be released with 3.4.0 @GaryQian |
…matching in build.gradle (flutter/flutter#112149)
…matching in build.gradle (flutter/flutter#112149)






Revert file naming convention of .aar files to support fuzzy matching in build.gradle on using maven-publish
Fix #111643
Fix #108000
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.