Collision between new core 1.5.0 versions and fragment-testing library transitively requiring 1.4.0

[mikehardy]

Description

androidx.fragment:fragment-testing requires androidx.test:core 1.4.0 - perhaps an uncoordinated release process between the dependent projects?

Steps to Reproduce

Have a project with fragments you want to test
Include androidx.fragment:fragment-testing dependency at their current stable version (1.5.4)
Include the new releases here (androidx.test:core:1.5.0)

Expected Results

Things work

Actual Results

If you run the dependencies target on your project you'll see that because fragment-testing needs to be on "debugImplementation" classpath (a quirk of that library https://developer.android.com/guide/fragments/test#declare-dependencies) you end up with a gradle dependency constraint failure where debugRuntime classpaths are on androidx.test:core 1.4.0 (from fragment-testing) but the test classpaths want 1.5.0

AndroidX Test and Android OS Versions

1.5.0 here (and espresso 3.5.0)

Link to a public git repo demonstrating the problem:

I'm working around it with this general strategy:

https://stackoverflow.com/a/56821518/9910298

    // debugImplementation required vs testImplementation: https://issuetracker.google.com/issues/128612536
    debugImplementation("androidx.fragment:fragment-testing:$fragments_version") {
        exclude group: 'androidx.test', module: 'core'
    }

I'm opening a PR with that change in a public repo and I'll update this after it is open (I want the link to this issue in the comment in the change I PR)

[mikehardy]

ankidroid/Anki-Android#12817 from our dependency tracking branch shows the commit history where I handled this, for reference

[brettchabot]

Similar to #1585 (comment) I think either the constraint that fragments-testing needs to be in debugImplementation needs to be removed, or gradle should just build a single self instrumented apk for tests. The latter would be a huge change so the former is probably more tractable.

Looks like the former issue is tracked here issuetracker.google.com/128612536. I'm going to close this bug in favor of tracking there.

[mikehardy]

Reasonable, but maybe a cross-pollinating nudge to the fragment team would be nice, such that they issue a release with a transitive dep on androidx.testing:core:1.5.0 perhaps ?

[mikehardy]

(especially given that holding our breaths on resolution of the now-2.5-year-old https://issuetracker.google.com/128612536 seems like waiting in vain...)

[mikehardy]

With apologies as I understand this generates another notification: but I was too hasty in my last comment - I've been personally tracking that issue on issuetracker for a long time and had lost hope, I assumed it was dead since last state was wontfix. I see you've reopened and proposed a real path forward. I have hope again! Sincere thanks.

[brettchabot]

See https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:fragment/fragment-testing/build.gradle and https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:gradle/libs.versions.toml;bpv=1. The AOSP androidx repo has already been globally updated to androidx.test:core:1.5.0, so fragment-testing should pick up this new version on their next release.

[brettchabot]

See update here https://issuetracker.google.com/issues/128612536#comment22