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

Migrating app to Androidx fails due to unability to transform bottomsheet-1.3.1 dependency #22

Closed
quarryman opened this issue Jun 18, 2019 · 16 comments · Fixed by #23
Closed

Comments

@quarryman
Copy link

Hi there.
As of today many faced an issue with building RN apps due to major release by google.
Details are here: RN issue

The main way to fix this is to upgrade your app to Androidx.
Android studio has a way to update dependencies sort of automatically, but bottomsheet is one that can not be updated.

Here is Gradle sync error after one adds

android.useAndroidX=true android.enableJetifier=true

to gradle.properties according to manual.

Unable to resolve dependency for ':react-native-bottomsheet@debug/compileClasspath': Failed to transform file 'bottomsheet-1.3.1.aar' to match attributes {artifactType=processed-aar} using transform JetifyTransform

This prevents me from migrating project to Androidx and thus from ability to further build.

I see this references native bottomsheet library and not your wrapper directly.
Hopefully you might know the reason Jettifier can not transform this exact aar or have other thoughts on this.

@JerakRus
Copy link

Faced with the exact same problem

@mikehardy
Copy link
Contributor

Curious if npm i --save-dev jetifier && npx jetify manages it for you? Also, worth noting that the primary way of solving this is not to upgrade to AndroidX, it's to run a gradle dependencies report and pin the versions on the libraries that are leaking in the AndroidX Play dependencies to the pre-AndroidX version so you are working immediately, then migrate to AndroidX in a measured way. This library may be doing something special in gradle though preventing jetification, which is why I'm curious, as we're working on it as a general strategy for react-native react-native-community/discussions-and-proposals#129

@JerakRus
Copy link

Read the above discussion in the topic. What you are doing is very important for the entire react-native community. But unfortunately now there is no possibility to try the solution, in my large enough project I had to return to android.supoort and now I am solving another problem with duplication of dependencies.

@quarryman
Copy link
Author

@mikehardy I read your comments on how to find dependencies causing androidx to be installed.
The issue with that approach is that once I identify firebase.x.x is the case, i downgrade it and some other modules, which results in constant errors like this
The library com.google.android.gms:play-services-basement is being requested by various other libraries at [[15.0.1,15.0.1]], but resolves to 17.0.0.

Bumping com.google.android.gms:play-services-basement version results in similar errors for other modules in cycle.

Having spent a day with this I just gave up.

Can you please explain what jetifier complains about when it's unable to transform file? It complains about compiled aar, what it does try to do with it? It would be good to understand possible reasons jettifier can not handle file.

@mikehardy
Copy link
Contributor

Sorry, I have no idea why jetifier wouldn't transform an aar - that basically it's only job, and I'm not sure why it would fail, I've never seen it which is why I took the time to collaborate here. If jetifier can fail it is important to know how.

I fully understand the pain of dependency hell and I'm sorry you're going through it. This will be a difficult few months while everything settles out. RN0.60 will also change to "pods first" for iOS at the same time it goes AndroidX, so it's going to be a bumpy ride, but also both are clearly the right decisions. It's just not easy taking in all the breaking changes of 3 ecosystems at once (iOS, Android, RN)

@quarryman
Copy link
Author

@mikehardy thanx for being responsive first of all.
I will additionally try 'npx jetify' right now and report the results.
IF ti fails can I provide anything to help investigate it?

@mikehardy
Copy link
Contributor

If npx jetify fails for any reason, please open an issue in the jetifier repo and I'll see what I can see. The console log of execution and then subsequent build results and your android/build.gradle and android/app/build.gradle would be important I guess. The repository is young so I have no template and have not seen problems yet. Thanks for giving it a spin, hope it helps though I will admit it sounds like you have a problem that is more thorny

@Doko-Demo-Doa
Copy link
Contributor

Yes I'm aware of this AndroidX problems recently. Will make necessary changes to it. However, because 0.60 is not out yet, I think I'm not going to support it right away.

@quarryman
Copy link
Author

@Doko-Demo-Doa do you mean you can handle it with RN wrapper?
Jettifier complains about native android bottomsheet which is this repo dependency

@mikehardy
Copy link
Contributor

@Doko-Demo-Doa that is a sensible position, I also maintain react-native-device-info and help on react-native-share and react-native-firebase and it does not make sense at the library level to move yet. Soon, but not yet. So we are trying to provide bridges like jetifier etc. The weird thing is that the bottomsheet aar won't jetify so users can't move to AndroidX and just transform things while you stay on support libraries. It's a failure that has no explanation yet, and doesn't require AndroidX support on your part, but is odd.

I will mention it will soon be possible to integrate the "bob" package, move your module to AndroidX, and use a bob build target to generate a "reverse jetified" aar at the build time then distribute it. Then you will have an AndroidX library (your main AAR) but also a support library (separate AAR) for apps to consume at their option

Good luck during this transition - not easy times for library maintainers ✊

@mikehardy
Copy link
Contributor

mikehardy commented Jun 18, 2019

(quick update: that PR on bob is merged, you can generate reverse-jetified AARs for support library consumers with trivial package.json directives now, I think...in case it's interesting)

@mikehardy
Copy link
Contributor

I found the problem. It is specific to this library, or even more precisely it is a bug in the packaging of the underlying library. soarcn/BottomSheet#142

The branch on that fork mentioned in that library is fully converted to AndroidX so may not be a viable solution here.

The library is effectively unmaintained. So I proposed a PR that fixes it and includes it directly #23

It works https://github.com/mikehardy/rn-androidx-demo/blob/master/make-demo.sh#L34

@quarryman
Copy link
Author

@JerakRus please read issue link in my initial comment.

@JerakRus
Copy link

@quarryman Thanks, I think I missed it. This will help me a lot! Then I will delete the previous comment.

@Doko-Demo-Doa
Copy link
Contributor

It should be solved now. Please use package v2.0.1
Let me know if there are still crashing, compiling errors,...

@mikehardy
Copy link
Contributor

I altered the dep to the standard npm install for bottomsheet in the AndroidX demonstrator I'm using to test/prove jetifier and it works great: mikehardy/rn-androidx-demo@0c9f4b2#diff-c8e33fe90e78d567b713e8dab48e5d87R34

Thanks @Doko-Demo-Doa

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 a pull request may close this issue.

4 participants