Build fails after updating to the latest NS.

NickIliev commented 6 years ago

From @mhmo91 on March 30, 2018 11:25

Which platform(s) does your issue occur on?

Android

Please provide the following version numbers that your issue occurs with:

CLI: 4.0.0-2018-03-27-11297
Cross-platform modules: ^4.0.0-2018-03-27-02
Runtime(s): 4.0.0-2018.3.22.2
Plugin(s): "nativescript-background-http": "^3.2.2", "nativescript-camera": "^3.2.1", "nativescript-cardview": "^2.0.5", "nativescript-checkbox": "^3.0.3", "nativescript-exit": "^1.0.1", "nativescript-feedback": "1.1.1", "nativescript-floatingactionbutton": "^4.1.3", "nativescript-geolocation": "^4.2.6", "nativescript-image-swipe": "^2.1.0", "nativescript-imagecropper": "^0.1.2", "nativescript-imagepicker": "^4.0.1", "nativescript-intl": "^3.0.0", "nativescript-iqkeyboardmanager": "^1.3.0", "nativescript-pdf-view": "^2.0.1", "nativescript-permissions": "^1.2.3", "nativescript-pro-ui": "next", "nativescript-textinputlayout": "^2.0.3", "nativescript-theme-core": "^1.0.4", "nativescript-toast": "^1.4.6", "ngx-order-pipe": "^2.0.1", "reflect-metadata": "^0.1.12", "rxjs": "^5.5.8", "tns-core-modules": "^4.0.0-2018-03-27-02", "zone.js": "^0.8.4"

Please tell us how to recreate the issue in as much detail as possible.

the build fails when upgraded the android version n the core modules

Copied from original issue: NativeScript/NativeScript#5602

NickIliev commented 6 years ago

The issue is reproducible with nativescript-feedback and the latest Android runtime - test application here

petekanev commented 6 years ago

@NickIliev @mhmo91 @EddyVerbruggen due to changes in the way plugins with standard Android counterparts are built the plugin will need to declare dependencies to any libraries referenced implicitly by the any plugins included in include.gradle.

In the case of nativescript-feedback using com.tapadoo.android:alerter - it uses the AppCompat support library. Adding the following to the include.gradle would fix the problem:

dependencies {    
    def supportVer = "27.0.1"
    if (project.hasProperty("supportVersion")) {
        supportVer = supportVersion
    }
    compile "com.android.support:appcompat-v7:$supportVer"
    compile 'com.tapadoo.android:alerter:1.0.6'
}

I don't think that the CLI will provide the supportVersion to the include.gradle when compiling the project separately, but it's certainly something that needs to be done as part of the changes that we are introducing - @Plamen5kov

Plamen5kov commented 6 years ago

The CLI can pass a "supportVersion" property to the build, but it's not recommended because that action would override the plugin-authors intention. By default, the CLI builds with this configuration. As @Pip3r4o mentioned there's no supportVersion there because we've no way of knowing what libraries will the plugin author need to build his/her plugin and this control is provided to the plugin authors through the use of include.gradle.

petekanev commented 6 years ago

@Plamen5kov I think that the supportVersion should be added in the configuration in case the plugin author has handling for it (by checking if it's been provided to the project), and leave the rest for the plugin author to handle.

Plamen5kov commented 6 years ago

While the CLI is building the plugin we've no way of knowing whether there is "supportVersion" in the user's app.gradle or not. If we want to add this configuration, we need to apply the app.gradle file to the project that's building the plugins similarly to what we do in the native project, but I think it's an overkill considering we have provided that control in the plugins' include.gradle file.

petekanev commented 6 years ago

@Plamen5kov can you confirm that when the CLI spawns the plugin build process, the PsupportVersion parameter is passed for the plugin authors to handle?

Plamen5kov commented 6 years ago

We can make the CLI pass the "supportVersion" property to the plugin build project, keeping in mind there might be issue with different plugins that need to be built with different "supportVersions".

petekanev commented 6 years ago

@NickIliev @mhmo91 @EddyVerbruggen We made slight changes to the way we build plugins, please install nativescript@rc and give the project another go.

NickIliev commented 6 years ago

@Pip3r4o @mhmo91 @EddyVerbruggen confirming this as resolved with nativescript@rc (used this test app)

mhmo91 commented 6 years ago

@NickIliev FYI, this didn't fix it, the update of the feedback plugin itself did, may be both, but just updating to ns@rc reproduced the same issue)) One last flag here, might seem irrelative but it's, NS need to provide a mechanism to force upgrading plugins to match compatibility with NS version so as the run time. https://github.com/telerik/nativescript-ui-feedback/issues/607#issuecomment-378880227

petekanev commented 6 years ago

@mhmo91 the NS cli will automatically update plugins if it detects the runtime is 4.+

mhmo91 commented 6 years ago

@Pip3r4o for me it didn't with or without runtime 4.+, n i didn't just try once, i tried many times, never got the upgrade plugin process. i'm on windows 10.

petekanev commented 6 years ago

@mhmo91 the original log posted in the issue is exactly that - the plugin being built by the CLI, separately from the application build.

NativeScript / android