[jira] [Resolved] (CB-9387) Document Android Plugin Compatibility

["Sergey Grebnov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CB-9387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Grebnov resolved CB-9387.
--------------------------------
    Resolution: Fixed
      Assignee:     (was: Sergey Grebnov)

> Document Android Plugin Compatibility
> -------------------------------------
>
>                 Key: CB-9387
>                 URL: https://issues.apache.org/jira/browse/CB-9387
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: Android, CLI, Docs
>            Reporter: Omar Mefire
>
> We (on the mailing list) agreed to the following steps to resolve this issue :
> - Update docs to ask plugin devs to use plugin.xml to define gradle dependencies
> - Add a comment to plugin template in CLI
> ======================================
> An email excerpt to help understand what's going on: 
> "
> Hi guys, I want to raise the following question - what we should recommend  plugin developers
> to avoid 'Multiple dex files defined' issue on Android, for example [3]
> UNEXPECTED TOP-LEVEL EXCEPTION:
>         com.android.dex.DexException: Multiple dex files define Landroid/support/v4/accessibilityservice/AccessibilityServiceInfoCompat$AccessibilityServiceInfoVersionImpl;
> To reproduce this problem you can add both Facebook [1] and PushPlugin[2] and then build android
> platform.
> This happens due to we still use jars to add plugin dependencies, but there are several very
> popular among them (like android-support, gson) so we bring the same dependencies several
> times so build fails.
> I think we should start recommending people to start adding utility/common/popular dependencies
> via corresponding gradle configuration (not using libs folder) as the only way to support
> multiple plugins which could rely on the same dependency. In this case gradle will be able
> to handle this situation correctly using its smart Dependency Management/Versioning logic
> [4].
> For example,
> <source-file src="src/android/com/plugin/android-support-v13.jar" target-dir="libs/" />
> ->
> <framework src="com.android.support:support-v13:21.0.0" />
> Disadvantage of this approach is that Ant build won't be supported (I know some tricky/more
> complex way to correctly support both Ant and Gradle but I don't think it is worth adding
> more complexity for plugins developers just to continue supporting Ant).
> Guys, any recommendations/thoughts how we should proceed in this situation? Maybe someone
> has better solution for this problem?
> [1] https://github.com/Wizcorp/phonegap-facebook-plugin  
> [2] https://github.com/phonegap-build/PushPlugin 
> [3] https://github.com/Wizcorp/phonegap-facebook-plugin/issues/1028 
> [4] https://docs.gradle.org/current/userguide/dependency_management.html
> Thx!
> Sergey
> "
> The rest of the email thread can be followed here:
> https://mail-archives.apache.org/mod_mbox/cordova-dev/201507.mbox/browser



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org