-
Notifications
You must be signed in to change notification settings - Fork 535
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
Fix #2643: Introduce canonical Bazel library structure & migrate util accessibility package #2775
Fix #2643: Introduce canonical Bazel library structure & migrate util accessibility package #2775
Conversation
Includes introducing new top-level package groups to simpify visibility management. This also establishes a pattern for excluding migrated production files.
This replaces #2668. |
NB: I am expecting some Bazel failures, so they will need to be fixed in a follow-up commit once the run finishes. |
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.
Approving for files for which I am the code-owner. Thanks.
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.
@BenHenning Added some suggestions and comments, PTAL.
utility/BUILD.bazel
Outdated
@@ -7,10 +7,15 @@ load("@dagger//:workspace_defs.bzl", "dagger_rules") | |||
load("@io_bazel_rules_kotlin//kotlin:kotlin.bzl", "kt_android_library") | |||
load("//utility:utility_test.bzl", "utility_test") | |||
|
|||
MIGRATED_PROD_FILES = glob(["src/main/java/org/oppia/android/util/android/**/*.kt"]) |
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.
We need to exclude the files inside accessibility
I guess you need to add a kdoc here similar to app/BUILD.bazel.
MIGRATED_PROD_FILES = glob(["src/main/java/org/oppia/android/util/android/**/*.kt"]) | |
MIGRATED_PROD_FILES = glob(["src/main/java/org/oppia/android/util/accessibility/**/*.kt"]) |
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.
Ah. I'm not sure how I missed this--thanks! Will update it locally a bit later and make sure everything's working as expected.
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.
Done.
private val accessibilityManager by lazy { | ||
context.getSystemService(Context.ACCESSIBILITY_SERVICE) as AccessibilityManager | ||
} | ||
|
||
override fun isScreenReaderEnabled(): Boolean { | ||
return accessibilityManager.isEnabled | ||
} |
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 guess you've missed adding the Kdocs for these two functions.
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 see just one function: isScreenReaderEnabled
. Am I maybe missing something?
Also, per https://developer.android.com/kotlin/style-guide#exception_overrides KDocs aren't needed on overrides. In general, we only add them in places where they add value, and method KDocs should always be describing the API introduced by a method. This fits better in the interface or superclass as that's outlining the API implementations need to follow.
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.
Got it
package_group( | ||
name = "oppia_api_visibility", | ||
packages = [ | ||
"//...", |
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.
Isn't this similar to oppia_binary_visibility
below?
if not what packages does each cover, when do we need to use oppia_api_visibility
& oppia_binary_visibility
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.
Hmm I tried making this clear in the documentation, but maybe it could use a bit more work. We'll generally be using API visibility unless something should only be accessible to the binary. I split them out to make the visibility groups themselves more explicit & to provide more control.
srcs = [ | ||
":AccessibilityCheckerImpl.kt", | ||
], | ||
visibility = ["//visibility:private"], |
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.
Do we need to specify this as it is private by default?
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.
Nope--good point. I'll remove this when I address the other code-based changes.
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.
Done.
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.
LGTM, thanks.
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.
Approving for files for which I am the code-owner. Thanks.
@@ -1,4 +1,50 @@ | |||
# TODO(#1532): Rename file to 'BUILD' post-Gradle. |
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.
Will we be replacing all instances of //visibility:public with one of these package groups?
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.
No, I don't think so. We may want to replace all instances with a package group, but the ones here are specifically corresponding to the types of libraries introduced in this PR.
kt_android_library( | ||
name = "impl", | ||
srcs = [ | ||
":AccessibilityCheckerImpl.kt", |
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.
Why use :<file_name>
here
"ObservableViewModel.kt", |
Here I've used only file name
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.
Mostly auto-complete. I believe they're equivalent, but it's less code-smell to omit the ':'. Will do that in a follow-up commit.
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.
Done.
@@ -533,6 +532,7 @@ kt_android_library( | |||
"//third_party:androidx_databinding_databinding-common", | |||
"//third_party:androidx_databinding_databinding-runtime", | |||
"//third_party:circularimageview_circular_image_view", | |||
"//utility/src/main/java/org/oppia/android/util/accessibility", |
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've missed this earlier.
Why are we adding the deps in app/BUILD.bazel
and why not utility/BUILD.bazel
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.
Because this is where the dependency is needed. It's not used by anything in utility, and to some extent, that's expected since utility is a collection of utility libraries to be used elsewhere in the codebase.
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.
Does that mean if there are any packages, which are directly used in the app module then we can directly add this in the app/BUILD.bazel?
but I think it would be better if we can pass it through utility/BUILD.bazel
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.
Yes, that's how it should be. We're planning to get rid of all the top-level BUILD files--libraries should always depend as directly on the thing they need as possible. Occasionally we may introduce libraries that export parts of their implementation (which can be useful when versioning APIs), but that's something that would come after everything is modularized.
Happy to chat about this further, and I'm sure @fsharpasharp can provide some insight here, too.
Addresses review comment.
I think all of your comments are now addressed @FareesHussain. PTAL & resolve if they are satisfactorily addressed. |
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.
LGTM, thanks.
Thanks! Looking at failures. |
Hmm, Bazel failures seem more of the incorrect affected targets computation. Gonna see if I can repro locally & actually fix the script. Gradle failure seems like a weird kapt flake I haven't seen before. |
Re-running tests to unblock down-stream work. Would like to try and investigate that Bazel issue, though. It's been eluding me... |
Aha, it appears the Gradle failures are real. Have some fixes to do. |
… util accessibility package (oppia#2775) * Refactor util a11y package with prod/test modules. * Hook up new accessibility module. Includes introducing new top-level package groups to simpify visibility management. This also establishes a pattern for excluding migrated production files. * Lint fixes. * Address reviewer comments. * Linter fix. * Use direct file names. Addresses review comment.
… migrate util accessibility package (oppia#2775)" This reverts commit a89c609.
… migrate util accessibility package (oppia#2775)" This reverts commit a89c609.
… util accessibility package (oppia#2775) * Refactor util a11y package with prod/test modules. * Hook up new accessibility module. Includes introducing new top-level package groups to simpify visibility management. This also establishes a pattern for excluding migrated production files. * Lint fixes. * Address reviewer comments. * Linter fix. * Use direct file names. Addresses review comment.
Fix #2643.
This is a replacement/continuation of #2668.
This PR does a few things:
One thing to note: long-term it's expected that modules will only be referenced in test dependencies & the root app binary targets. However, at the moment production modules need to be included in the main
app
library due to being tightly coupled with the Dagger component classes. This will continue to be the case until #1720 is finished (since then build graph inclusion of a module predicates whether it's included in the generated component).