Give the git and projects features matching package roots - #86
Merged
Conversation
This file contains hidden or 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
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.
Why
Two feature modules had package roots that did not name them, which the earlier dependency audit repeatedly tripped over:
:feature:gitdeclaredfeature.editor.git.*— its code lived under the editor's namespace, so a search for git symbols found editor-shaped names and vice versa:feature:projectsdeclaredfeature.hub,feature.createproject,feature.openproject,feature.clonerepo,feature.folderpicker— noprojectssegment at allWhen a module's package does not say which module owns it, no import-based reasoning is reliable. That already produced a wrong answer once during the stale-dependency audit.
The contract modules also inherited
publicby default, which is the wrong default for a module whose entire purpose is a reviewable surface.What changed
feature.editor.git.*→feature.git.*(52 files)feature.{hub,createproject,openproject,clonerepo,folderpicker}→feature.projects.{…}(30 files)explicitApi()on:feature:git:apiand:feature:buildrun:api, with every declaration now stating its visibilityEvery package root in the repo now belongs to exactly one Gradle module, and each feature module's package names it.
Behavior
No behavior change. Package declarations, imports, and visibility modifiers that were already implicit.
Tests
Verification
./gradlew test detekt verifyModuleBoundaries :app:assembleDebug— BUILD SUCCESSFUL. Boundary report: 0 baseline entries, 0 violations.Verified on an emulator, since a package rename is exactly the kind of change that compiles and then fails to resolve a resource or a reflective lookup at runtime:
Resources$NotFoundException,AbstractMethodErrororNoClassDefFoundErrorin logcatNote on the detekt baselines: adding explicit
publicmodifiers changes the signature strings that key baseline entries, so the two entries in:feature:git:apiwere re-keyed rather than regenerated. Nothing new is absorbed.