cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: Discuss Android plugin compatibility problem
Date Sat, 18 Jul 2015 01:53:18 GMT
+1 to doc and maybe add as a comment in plugin template in cli

Having low number of dependencies or not all is something is good that we
aim for.
On Fri, Jul 17, 2015 at 11:59 AM Sergey Grebnov (Akvelon) <
v-segreb@microsoft.com> wrote:

> Agree, sounds like a good plan. I'm going to review and fix this in most
> popular cordova plugins and having this as an official recommendation I can
> refer to will be great (part of Android plugins dev guide).
>
> PS. I've also double checked Cordova core plugins and they are not
> affected (there are actually not so much dependencies at all).
>
> -----Original Message-----
> From: Mefire O. [mailto:ommenjik@microsoft.com]
> Sent: Friday, July 17, 2015 6:39 PM
> To: dev@cordova.apache.org
> Subject: Re: Discuss Android plugin compatibility problem
>
> So, it seems like mechanisms are already in place to enable us to do what
> we wanna do here.
>
> The actionable step I'm seeing here is 'updating the docs to ask plugin
> devs to use plugin.xml to define gradle dependencies'.
>
> If you folks agree with what this actionable item, I will create a jira
> item to track it.
>
> Thanks,
>
> On Jul 17, 2015 7:59 AM, Joe Bowser <bowserj@gmail.com> wrote:
> I'm fine with it.  I just spaced out and forgot we did that for Crosswalk.
> I thought we had a reference to a gradle file instead.
>
> On Fri, Jul 17, 2015 at 6:14 AM Carlos Santana <csantana23@gmail.com>
> wrote:
>
> > What's the problem Joe? Having declaring cradle dependencies in
> > plugin.xml I think is a good thing. At high level a plugin should be
> > able to some how declare its dependencies for things located in
> > gradle/maven via plugin.xml, a metada file, or hook.
> > We in IBM are using gradle in plugin.xml for some plugins we do, we
> > want to do the same for iOS with cocoapods
> >
> > On Fri, Jul 17, 2015 at 12:53 AM Joe Bowser <bowserj@gmail.com> wrote:
> >
> > > Wait, yeah, plugin.xml does handle that.  I was thinking config.xml.
> > WTF?
> > >
> > > On Thu, Jul 16, 2015 at 9:21 PM Carlos Santana
> > > <csantana23@gmail.com>
> > > wrote:
> > >
> > > > Steve plugin.xml already supports declaring gradle deps
> > > >
> > > > On Thu, Jul 16, 2015 at 1:29 PM Joe Bowser <bowserj@gmail.com>
> wrote:
> > > >
> > > > > Ideally Maven should handle all this shit, and it should be
> > invisible.
> > > > Our
> > > > > plugin system should not handle Java dependencies or any other
> > platform
> > > > > dependencies, and we should work behind the scenes to make this
> > > > > work
> > > like
> > > > > how Crosswalk works.
> > > > >
> > > > > On Thu, Jul 16, 2015 at 10:18 AM Steven Gill
> > > > > <stevengill97@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Would this be added to plugin.xml?
> > > > > >
> > > > > > On Thu, Jul 16, 2015 at 10:09 AM, Mefire O. <
> > ommenjik@microsoft.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 on moving deps to gradle.
> > > > > > >
> > > > > > > On Jul 16, 2015 9:37 AM, Carlos Santana
> > > > > > > <csantana23@gmail.com>
> > > > wrote:
> > > > > > > you mean the scripts in cordova-android right? then yes
> > > > > > >
> > > > > > > +1 create jira bug, enhancements etc.. if doesn't get track
> > > > > > > +it
> > > > doesn't
> > > > > > get
> > > > > > > done
> > > > > > >
> > > > > > > On Thu, Jul 16, 2015 at 12:26 PM Joe Bowser
> > > > > > > <bowserj@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > > Is there a bug created for this? It sounds like we
should
> > > > > > > > have
> > > the
> > > > > > local
> > > > > > > > scripts handle dependency adding on Android.
> > > > > > > >
> > > > > > > > On Thu, Jul 16, 2015 at 9:14 AM Carlos Santana <
> > > > csantana23@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1 gradle declared dependencies only, cli to
warn users
> > > > > > > > > +about
> > > > > plugins
> > > > > > > > > having libraries that will conflict, future is
gradle no
> > > > > > > > > ANT
> > > I'm
> > > > ok
> > > > > > to
> > > > > > > > > start deprecating ant going forward.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Jul 16, 2015 at 11:27 AM Sergey Grebnov
> > > > > > > > > (Akvelon) < v-segreb@microsoft.com> wrote:
> > > > > > > > >
> > > > > > > > > > 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/AccessibilityServiceInfoCompa
> > t$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/102
> > > > > > 8
> > > > > > > > > > [4]
> > > > > > > >
> > > > https://docs.gradle.org/current/userguide/dependency_management.ht
> > > > ml
> > > > > > > > > >
> > > > > > > > > > Thx!
> > > > > > > > > > Sergey
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail:
> > > > > > > > > > dev-unsubscribe@cordova.apache.org
> > > > > > > > > > For additional commands, e-mail:
> > dev-help@cordova.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message