Fix Android dependencies and build errors #2720

friederbluemle · 2019-03-03T12:55:29Z

Does any other open PR do the same thing?

No

What issue is this PR fixing?

Currently, the yarn tasks start:android and run:android to build and run the Android version are failing on the master branch with the following error:

* What went wrong:
A problem occurred evaluating project ':react-native-maps-lib'.
> Could not find method compileOnly() for arguments [com.facebook.react:react-native:+] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

This is caused by partially and incorrectly updated dependencies of the Android build system, which was addressed by updating the dependencies as described below. Many obsolete and unused leftover files of old Gradle wrapper installations and a couple of files from the Eclipse days were removed as well.

The three main things this PR addresses is:

Update Gradle wrapper to 5.2.1 (latest stable version)
Update Android Gradle plugin to 3.2.1 (version that ships with latest version of React Native)
Remove unused appcompat-v7 dependency from library project

See individual commits for more details.

How did you test this PR?

react-native start
yarn run-android
yarn run-ios

Correct behavior (build and run) was verified using an Android device, an Android emulator, and an iOS simulator.

Includes and closes #2712
Also fixes #2663

_{^{Once approved, please use a normal GitHub merge (i.e. NO rebase/squash merge) to integrate the commit(s) from the branch of this pull request. The changes are broken up into meaningful, atomic commits, and my branch should already be up-to-date with the latest target branch. If it isn't, or if you'd like me to combine something, please let me know, and I will make the necessary updates as soon as possible. Thank you!}}

alvelig · 2019-03-03T13:49:11Z

LGTM @rborn 🐽

radeno · 2019-03-04T19:41:50Z

@friederbluemle
I like this PR, when i created first PR for react-native-maps it was pain for me to run test environment. Almost everything was outdated and not working. So i am welcoming it.

What i recommend by mine good practice is to separate iOS and Android specific changes as two PRs. It could be checked and tested separately. This PR is not change in couple files, but 26. It could helps to merge it faster when it will be as two independent pull requests.

Do you think use Gradle 5.2.x is good idea? RN 0.58 uses 4.10.2, even RN0.59 will use 4.10.2. Gradle 5.0 lands in RN master branch just 12 days ago. I think 4.10 is safe now.

radeno · 2019-03-04T19:46:47Z

Anyway iOS changes looks good to me.
All chagnes are created by Cocoapods automatic scripts. So its safe.

friederbluemle · 2019-03-05T06:05:05Z

@radeno - Thanks a lot for the review and the comment! 👍

As you suggested, I downgraded the Gradle wrapper to 4.10.3 (like you said, RN currently ships with the 4.10.x version)

I also excluded the ios changes (Podfile.lock) - I'll open a separate PR once this one is in. It should make the review a bit easier.

radeno · 2019-03-05T06:47:29Z

@friederbluemle i'm not an Android expert so lets get inspiration from https://github.com/react-native-community/react-native-netinfo which is community repo from other community repos taking inspiration in Lean Core initiative.

All gradle files from root folder should be deleted or moved to right place. We need only related for build in lib/android and example directory example/android, It is little bit mess, because gradle config files are not separated by scope "build" or "example". But there is third scope, global. Which is what you don't bring with this PR, it is existed legacy. So lets clean it up.

Can you check it please?

friederbluemle · 2019-03-05T07:12:15Z

@radeno - Yes good point. Do you suggest we should also do it in this PR as well or do keep it separate? As you mentioned I am not introducing any new legacy tech debt with this PR (only clean up, removing files, and updating/moving existing files).

I agree there is more follow up work to be done. I have some pending wip on a separate branch locally that moves the wrapper from the root directory (I think that should be taken care of separately).

radeno · 2019-03-05T08:30:51Z

@friederbluemle in my opinion it should be good move to transfer them into correct directories by this PR.
Running examples on actual Android studio is broken anyway without your PR. And removing global Gradle scope is nice to have.

Most gradle files from root directory belongs to example directory. So i think, yes lets move it.

- Delete compiled files - Remove obsolete Gradle wrapper leftover - Remove Eclipse project leftover

- Update Gradle wrapper to 4.10.3 - Update Android Gradle plugin to 3.2.1 - Remove unused appcompat-v7 dependency from lib project

friederbluemle · 2019-03-08T10:16:48Z

@radeno - To make the PR review easier and lower the impact/risk, would it be possible to use two PRs? This PR here does not create any new files, just updates existing ones. I will open a follow up PR right after this on is in. We are already successfully using an internal fork with the changes on this PR.

radeno · 2019-03-08T12:01:34Z

@friederbluemle for me it doesnt matter because test case is easy. Will it work or will not :) but i am not maintaner.
Cc @alvelig @rborn

alvelig · 2019-03-08T14:14:01Z

LGTM @rborn @christopherdro @salah-ghanim

rborn · 2019-03-08T14:32:18Z

@alvelig @christopherdro @salah-ghanim LGTM

grifotv · 2019-03-09T00:32:14Z

@friederbluemle unfortunately I'm unable to run react-native run-android since this has been merged.

info Building and installing the app on the device (cd android && ./gradlew app:installDebug)...

> Configure project :app
Reading env from: .env.development

FAILURE: Build failed with an exception.

* Where:
Script '/my_project_path/node_modules/react-native-maps/lib/android/gradle-maven-push.gradle' line: 48

* What went wrong:
A problem occurred configuring project ':react-native-maps'.
> Could not get unknown property 'GROUP' for object of type org.gradle.api.publication.maven.internal.deployer.DefaultGroovyMavenDeployer.

react-native: next
react-native-maps: https://github.com/react-community/react-native-maps.git

Should I create an issue?

Thanks

friederbluemle · 2019-03-09T08:25:00Z

@grifotv Thanks for the report. I'm checking now!

friederbluemle · 2019-03-09T09:08:01Z

Confirming the build error that @grifotv reported.

I missed including a small change in this PR that I had locally. Sorry about that.

I opened a PR with the fix here: #2727

@christopherdro @alvelig @rborn - Please check, hopefully we can get this merged quickly. Thanks and sorry again for the oversight!

alvelig · 2019-03-09T14:07:27Z

Merged

rborn · 2019-03-15T09:01:32Z

@friederbluemle it looks like some people still have issues with a missing line in build.gradle
implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"

#2695 (comment)

This PR only includes it in example, but not in the lib/android/build.gradle

Do we need to add it there or they are using an older version of the module? ( didn't have time to test :( )
Thanks

friederbluemle · 2019-03-15T09:50:52Z

@rborn Thanks for the heads up! Looking into it!

friederbluemle · 2019-03-15T14:35:55Z

@rborn - Looking at the comments in the other thread, these people were not using the master branch of react-native-maps (i.e. the build.gradle file posted looks different than the one currently on master).

I checked the code again, and there are definitely no dependencies on appcompat-v7 in the library project.

However, there are a couple of dependencies on android.support.v4 in AirMapView. So, technically support-v4 should explicitly be declared as a dependency in build.gradle. For now, it's probably best to re-add appcompat-v7. See #2743.
Note that support-v4 is also pulled in transitively by many other libraries, for example play-services-base:

$ ./gradlew :react-native-maps-lib:dependencies

[...]
+--- com.google.android.gms:play-services-base:16.1.0
|    +--- com.google.android.gms:play-services-basement:16.2.0
|    |    \--- com.android.support:support-v4:26.1.0
[...]

The issues people are having are most likely related to the way dependencies are declared in the app project, and the resulting conflicts.

https://docs.gradle.org/current/userguide/customizing_dependency_resolution_behavior.html

Other possible solutions/workarounds include:

    implementation ('com.facebook.react:react-native:+') {
        exclude group: 'com.android.support', module: 'support-v4'
    }

or

subprojects {
  project.configurations.all {
    resolutionStrategy.eachDependency { details ->
      if (details.requested.group == 'com.android.support'
          && details.requested.name == 'support-v4') {
        details.useVersion '28.0.0'
      }
    }
  }
}

Ideally there should be no need to modify files inside of the node_modules folder!

rborn · 2019-03-15T14:43:11Z

@friederbluemle thank you very much for the investigation. Let's keep it like his for now and keep an eye on it.
I expect to upgrade a project to last RN soon so I'll also test first hand.

Thanks again ❤️

arosendorff · 2019-03-25T14:54:30Z

Sorry if I missed it, but is there a reason why this PR takes out the ability of react-native-maps to use the googlePlayServicesVersion in your top level gradle file? That ability was added in PR #2047

friederbluemle · 2019-03-26T11:25:48Z

@arosendorff - Good question!

The library (and its source code) is built against and guaranteed to work with one specific version of the play-services-* artifacts. The same is true for all other dependencies. Therefore, making it possible to externally modify the dependency versions used (without looking and checking the source code) leads to brittle and unpredictable builds.

However: It does seem like this unfortunately is the prevalent, "recommended", and only (?) way dependencies of React Native apps are handled, at least at the moment.
In many cases, "small" updates (i.e. the patch component) will work without issues and don't require code updates. I assume the main reason for the desire to set this externally is to avoid certain types of dependency mismatch errors during the build. Being able to adjust the versions with the ext variables offers a "simple" solution to align transitive dependencies used by several referenced packages, though there is no guarantee it will work, and there are other ways to prevent mismatch errors as well.

In any case, I do admit this was a mistake on my end, and it's not the job of this repository/library to change the way React Native dependencies are consumed, so I've added this functionality back in this PR right here: #2765

rborn · 2019-03-26T13:13:33Z

@arosendorff #2765 was merged, please test with the last master. Thanks for your observation 🤗

arosendorff · 2019-03-26T14:34:08Z

@friederbluemle I get what you're saying about the required play-services-* artifacts. Perhaps it's worth mentioning in the readme that while the module will honour your global configuration, there is a recommended version you should use to ensure everything runs smoothly?

@rborn Perfect, thanks so much! 🙂

* Update yarn.lock * Remove obsolete files and folders - Delete compiled files - Remove obsolete Gradle wrapper leftover - Remove Eclipse project leftover * Update .gitignore * Fix Android dependencies and build errors - Update Gradle wrapper to 4.10.3 - Update Android Gradle plugin to 3.2.1 - Remove unused appcompat-v7 dependency from lib project

appli-intramuros · 2020-11-17T23:12:50Z

Hello !

Since this PR is merged, the build gradle parameter: androidMapsUtilsVersion is not use anymore. (the commit: 8811ba3#diff-c6899e54b9ed67b2d9034a841311198095bc6419675fc9f59874312c341fe414L59).

Is it normal ?

friederbluemle · 2020-11-17T23:47:50Z

Hello !

Since this PR is merged, the build gradle parameter: androidMapsUtilsVersion is not use anymore. (the commit: 8811ba3#diff-c6899e54b9ed67b2d9034a841311198095bc6419675fc9f59874312c341fe414L59).

Is it normal ?

Hi @appli-intramuros - Yes, this is normal. If you require a different version of the dependency, you could try Gradle dependency substitution (only works for versions that are backwards compatible) - or - (preferred) submit a PR to this repo and update to the latest version.

friederbluemle force-pushed the fix-android-build branch from 5921602 to 4f6c684 Compare March 4, 2019 11:24

friederbluemle force-pushed the fix-android-build branch from 4f6c684 to 39590ec Compare March 5, 2019 06:00

friederbluemle force-pushed the fix-android-build branch from 39590ec to 58f8bcc Compare March 5, 2019 06:06

friederbluemle added 4 commits March 8, 2019 18:13

Update yarn.lock

fafb039

Update .gitignore

9a1c9ab

Remove obsolete files and folders

9fe2a50

- Delete compiled files - Remove obsolete Gradle wrapper leftover - Remove Eclipse project leftover

Fix Android dependencies and build errors

8811ba3

- Update Gradle wrapper to 4.10.3 - Update Android Gradle plugin to 3.2.1 - Remove unused appcompat-v7 dependency from lib project

friederbluemle force-pushed the fix-android-build branch from 58f8bcc to 8811ba3 Compare March 8, 2019 10:14

christopherdro merged commit d835964 into react-native-maps:master Mar 8, 2019

friederbluemle deleted the fix-android-build branch March 9, 2019 08:24

friederbluemle mentioned this pull request Mar 9, 2019

Include gradle-maven-push only when props are set #2727

Merged

rborn mentioned this pull request Mar 14, 2019

Unable to resolve Gradle dependencies #2695

Closed

friederbluemle mentioned this pull request Mar 15, 2019

Add appcompat-v7 dependency declaration to lib #2743

Merged

friederbluemle mentioned this pull request Mar 26, 2019

Android: Allow setting of play-services version through ext #2765

Merged

This was referenced Mar 26, 2019

Android cleanup: little improved way of getting SDK values #2398

Closed

update android build configuration for gradle 3+ in example project #2342

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix Android dependencies and build errors #2720

Fix Android dependencies and build errors #2720

friederbluemle commented Mar 3, 2019

alvelig commented Mar 3, 2019

radeno commented Mar 4, 2019 •

edited

Loading

radeno commented Mar 4, 2019

friederbluemle commented Mar 5, 2019

radeno commented Mar 5, 2019 •

edited

Loading

friederbluemle commented Mar 5, 2019

radeno commented Mar 5, 2019

friederbluemle commented Mar 8, 2019

radeno commented Mar 8, 2019 •

edited

Loading

alvelig commented Mar 8, 2019

rborn commented Mar 8, 2019

grifotv commented Mar 9, 2019

friederbluemle commented Mar 9, 2019

friederbluemle commented Mar 9, 2019

alvelig commented Mar 9, 2019

rborn commented Mar 15, 2019

friederbluemle commented Mar 15, 2019

friederbluemle commented Mar 15, 2019 •

edited

Loading

rborn commented Mar 15, 2019

arosendorff commented Mar 25, 2019 •

edited

Loading

friederbluemle commented Mar 26, 2019

rborn commented Mar 26, 2019

arosendorff commented Mar 26, 2019 •

edited

Loading

appli-intramuros commented Nov 17, 2020 •

edited

Loading

friederbluemle commented Nov 17, 2020

Fix Android dependencies and build errors #2720

Fix Android dependencies and build errors #2720

Conversation

friederbluemle commented Mar 3, 2019

Does any other open PR do the same thing?

What issue is this PR fixing?

How did you test this PR?

alvelig commented Mar 3, 2019

radeno commented Mar 4, 2019 • edited Loading

radeno commented Mar 4, 2019

friederbluemle commented Mar 5, 2019

radeno commented Mar 5, 2019 • edited Loading

friederbluemle commented Mar 5, 2019

radeno commented Mar 5, 2019

friederbluemle commented Mar 8, 2019

radeno commented Mar 8, 2019 • edited Loading

alvelig commented Mar 8, 2019

rborn commented Mar 8, 2019

grifotv commented Mar 9, 2019

friederbluemle commented Mar 9, 2019

friederbluemle commented Mar 9, 2019

alvelig commented Mar 9, 2019

rborn commented Mar 15, 2019

friederbluemle commented Mar 15, 2019

friederbluemle commented Mar 15, 2019 • edited Loading

rborn commented Mar 15, 2019

arosendorff commented Mar 25, 2019 • edited Loading

friederbluemle commented Mar 26, 2019

rborn commented Mar 26, 2019

arosendorff commented Mar 26, 2019 • edited Loading

appli-intramuros commented Nov 17, 2020 • edited Loading

friederbluemle commented Nov 17, 2020

radeno commented Mar 4, 2019 •

edited

Loading

radeno commented Mar 5, 2019 •

edited

Loading

radeno commented Mar 8, 2019 •

edited

Loading

friederbluemle commented Mar 15, 2019 •

edited

Loading

arosendorff commented Mar 25, 2019 •

edited

Loading

arosendorff commented Mar 26, 2019 •

edited

Loading

appli-intramuros commented Nov 17, 2020 •

edited

Loading