Skip to content
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

Updated dependencies for v2022.1 #4883

Merged
merged 20 commits into from
Nov 22, 2021

Conversation

grzesiek2010
Copy link
Member

@grzesiek2010 grzesiek2010 commented Oct 28, 2021

What has been done to verify that this works as intended?

I've run automated tests.

Why is this the best possible solution? Were any other approaches considered?

This is what we do after every release.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

It doesn't require testing.

Do we need any specific form for testing your changes? If so, please attach one.

No.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

  • run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
  • verified that any code or assets from external sources are properly credited in comments and/or in the about file.
  • verified that any new UI elements use theme colors. UI Components Style guidelines

@grzesiek2010 grzesiek2010 force-pushed the v2022.1_dependencies branch 2 times, most recently from 430b1e8 to 9b9e65f Compare November 3, 2021 11:56
@grzesiek2010 grzesiek2010 changed the title V2022.1 dependencies Updated dependencies for v2022.1 Nov 3, 2021
@grzesiek2010 grzesiek2010 marked this pull request as ready for review November 3, 2021 12:27
.editorconfig Outdated
@@ -0,0 +1,2 @@
[*.{kt,kts}]
disabled_rules=import-ordering
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disabled checking import ordering because it has always been kind of annoying especially that in Android Studio we don't have any easy way to reorder imports so that ktlint is satisfied. And now with new updates they changed something and I was asked to change the order of menu imports despite the fact everything was fine before.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there no way to fix using "Import layout" in Android Studio > Preferences > Editor > Code Style > Kotlin? It would be nice to keep ordering enforced, so we don't end up causing accidental changes in files using "optimize imports".

Copy link
Member Author

@grzesiek2010 grzesiek2010 Nov 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I downgraded ktlint because they might have something broken regarding the ordering of imports in the newest version if what we have on master is no longer accepted. I even tried different settings like:

ij_kotlin_imports_layout=* # alphabetical with capital letters before lower case letters (e.g. Z before a), no blank lines
ij_kotlin_imports_layout=*,java.**,javax.**,kotlin.**,^ # default IntelliJ IDEA style, same as alphabetical, but with "java", "javax", "kotlin" and alias imports in the end of the imports list

to no avail so let's check it after next release.

@@ -25,12 +25,10 @@ class FormMetadataTest {
fun startGeopoint_withCachedFormDefinition_doesNotCauseError() {
rule.startAtMainMenu()
.copyForm("start-geopoint.xml")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They just decided we shouldn't use blank lines like that pinterest/ktlint#1248
I could disable the rule but it would also mean disabling checking blank lines in all the other cases (that I like).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel pretty strongly about keeping those blank lines. In a lot of case it might not make sense, but I do think it helps readability in our UI tests when related groups are broken up by a blank line like that. Can we put ignore the rule and revert related changes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No because the rule is no-consecutive-blank-lines so as I said if you disable it you disable checking all the other cases where having blank lines is obviously a bad thing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry what I mean is that I'd be happy to just disable that rule. I feel like the blank lines are useful enough in some places to make up for other places they might appear and not look quite right.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure? I'm going to repeat: if we do that you can add multiple blank lines in many different ways in the codebase and it won't be detected. I didn't want to do that because in all the other cases detecting blank lines worked well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, you mean it's not just for chains? Sorry you're right I'm misunderstanding and that it's not worth disabling.

Copy link
Member Author

@grzesiek2010 grzesiek2010 Nov 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not just for chains?

yeah it's a broader rule.

You know what? now as I downgraded ktlint because of that problem with imports (see above) I can bring those lines back too. So maybe let's do that for now and complain about that in their repo (and ask if we can disable this particular check somehow if they are unwavering). What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, agreed! It does seem a little broken as a line followed by a comment shouldn't count as "consecutive" blank lines. I can post a reply (seeing as I seem to care so much 😆).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I reverted that commit.

@@ -97,7 +97,7 @@ object Dependencies {
const val hamcrest = "org.hamcrest:hamcrest:2.2"
const val powermock_module_junit4 = "org.powermock:powermock-module-junit4:2.0.9"
const val powermock_api_mockito2 = "org.powermock:powermock-api-mockito2:2.0.9"
const val robolectric = "org.robolectric:robolectric:4.6.1"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to downgrade robolectric for now because of this issue robolectric/robolectric#6593 there is a workaround there but I don't like it so I prefer waiting for a better version of this dependency.

build.gradle Outdated
@@ -15,7 +15,7 @@ buildscript {

dependencies {
classpath 'com.android.tools.build:gradle:7.0.3'
classpath 'com.google.gms:google-services:4.3.10'
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The updated broke lint throwing hundreds Unused resource errors so I downgraded for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's pull out a separate issue for this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually don't file new issues for every dependency that I need to skip during upgrading. Usually if there is something wrong next time it works fine. If during next code freeze the same issue occurs then I will do that.

Copy link
Member

@seadowg seadowg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to merge once we unfreeze!

@grzesiek2010
Copy link
Member Author

@seadowg

I've added (or actually removed :)) some more stuff:

  • ButterKnife since we should use view binding instead
  • findbugs since it hasn't been used for a long time either way and I think we don't need to bring it back. It checks only java code but now most of the new code is in Kotlin.

@grzesiek2010 grzesiek2010 added this to the v2022.1 milestone Nov 18, 2021
@grzesiek2010 grzesiek2010 merged commit 1b310ce into getodk:master Nov 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants