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

Define version constraints for sentry-android-fragment #2025

Closed
romtsn opened this issue May 8, 2022 · 7 comments
Closed

Define version constraints for sentry-android-fragment #2025

romtsn opened this issue May 8, 2022 · 7 comments
Labels
enhancement New feature or request Platform: Android

Comments

@romtsn
Copy link
Member

romtsn commented May 8, 2022

Description

The sentry-android-fragment module depends on androidx.fragment:fragment-ktx. This one, in turn, depends on androidx.lifecycle:lifecycle-viewmodel-ktx, which had at some point the following change (moving ViewModelLazyKt from viewmodel-ktx to viewmodel):

This change can cause Duplicate classes check to fail if the versions of androidx.lifecycle:viewmodel and androidx.lifecycle:viewmodel-ktx do not much (e.g. viewmodel comes as a transitive dependency with a higher version than viewmodel-ktx, where this change has been introduced).

In theory, we could mitigate this issue by declaring dependency constraints for androidx.fragment:fragment-ktx, where we can define a range of allowed transitive dependency versions (viewmodel-ktx in this case).

Encountered this issue when using our SAGP auto-installation feature on this sample project.

@marandaneto
Copy link
Contributor

Does it help if we stop using fragment-ktx and use only fragment?

@marandaneto
Copy link
Contributor

For dependency constraints, we'd need to support Gradle Module Metadata, so it'd not work if using another build system, I guess.

@romtsn
Copy link
Member Author

romtsn commented May 9, 2022

Yeah, but not sure if it's a problem in other build systems (probably it is, but the fraction of those is just too small). So I guess we are good here with just doing it for gradle.

Using fragment would help for this particular case, but again can be a problem, if someone is using viewmodel-ktx of an older version, where this class is still present.

@marandaneto
Copy link
Contributor

Using fragment would help for this particular case, but again can be a problem, if someone is using viewmodel-ktx of an older version, where this class is still present.

Then it's an error on their end since we don't use ViewModelLazyKt, right?

@romtsn
Copy link
Member Author

romtsn commented May 9, 2022

yeah, kinda. They would need to update their viewmodel-ktx to the later version. I mean, this can be fixed on the user's site even now, by declaring the explicit dependency to viewmodel-ktx, I just thought of a nice way to prevent this issue for the consumers. Can be low priority for sure (or can be resolved by bumping fragment-ktx, but needs a mention in the migration docs with a min supported version of viewmodel-ktx then)

@bruno-garcia
Copy link
Member

We decided to add a troubleshooting page entry for this

@romtsn
Copy link
Member Author

romtsn commented Jul 19, 2022

So this was actually resolved by #2175 as we declare the transitive dependencies as compileOnly now, and will use whatever the user has defined in their app at runtime, so this problem will not appear anymore.

@romtsn romtsn closed this as completed Jul 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Platform: Android
Projects
Archived in project
Development

No branches or pull requests

3 participants