cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Plugin packages on Android
Date Mon, 15 Jul 2013 19:58:42 GMT
I feel like Android is in good shape for the most part, but I can't
say the same about the plugins or the CLI that I'm currently using to
load them, since I haven't tested today's changes yet.  That being
said, I think you guys have some open issues still, like the
UriResolvers, and I did see a jUnit test fail when I was in the tests
directory working with Robotium (which now works with Cordova), which
is why I'm wondering why we're talking about polish.



On Mon, Jul 15, 2013 at 12:46 PM, Andrew Grieve <agrieve@chromium.org> wrote:
> Joe - what non-polish items are left for Android? If you're feeling like
> you have too much to do this week, maybe you can delegate some tasks?
>
>
> On Mon, Jul 15, 2013 at 3:27 PM, Filip Maj <fil@adobe.com> wrote:
>
>> I think what you're saying Andrew is true under the assumption that
>> plugins are ONLY consumed via the JS api. I'm not sure whether that
>> assumption is correct in all cases.
>>
>> In any case, clarifying this point (dependency "scope" we could call it,
>> perhaps?) seems like a good idea.
>>
>> On 7/15/13 12:14 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>>
>> >-1 to shims. A plugin's java package name shouldn't be considered a part
>> >of
>> >its API. That's why there is a mapping in the config.xml.
>> >
>> >Shouldn't have to change any require() statements, or any JS at all. Those
>> >use plugin IDs, not java namespaces.
>> >
>> >Replace-all on the package statement at the top of the file, and change
>> >the
>> >reference in plugin.xml. I'd put this change in the "polish" category.
>> >That's what we should be doing now, no?
>> >
>> >
>> >
>> >
>> >On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj <fil@adobe.com> wrote:
>> >
>> >> +1 wait until 3.1.
>> >>
>> >> +1 add shims for less breakage
>> >>
>> >> Also worth pointing out that we'll need to add this to the deprecation
>> >> list on the wiki
>> >>
>> >> On 7/15/13 11:30 AM, "Simon MacDonald" <simon.macdonald@gmail.com>
>> >>wrote:
>> >>
>> >> >The reason things broke back then was we didn't leave in shims to point
>> >> >anyone compiling against com.phonegap.api to org.apache.cordova.api.
>> >>That
>> >> >was quickly corrected.
>> >> >
>> >> >I agree with the package name change but with 3.0 shipping this
>> >>week(?).
>> >> >It
>> >> >should probably wait until the next version.
>> >> >
>> >> >
>> >> >Simon Mac Donald
>> >> >http://hi.im/simonmacdonald
>> >> >
>> >> >
>> >> >On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux <b@brian.io> wrote:
>> >> >
>> >> >> No. You are proposing an API change. A package is most certainly
a
>> >> >> part of the API! When we moved from `com.phonegap` to `org.apache`
>> >> >> there was a huge outcry b/c it broke all existing community plugins.
>> >> >>
>> >> >> I'm completely open to changing stuff for 3.0 but, again, what
>> >> >> specifically are you proposing we change?
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI <anis.kadri@gmail.com>
>> >> >>wrote:
>> >> >> > I agree. The only downside I see is that it will be hard to
>> >>dissociate
>> >> >> core
>> >> >> > plugins from other but I don't think it's really that important.
>> >>Also
>> >> >> > because it's not a giant change it could happen for 3.0.
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren <maxw@chromium.org>
>> >> >> wrote:
>> >> >> >
>> >> >> >> I'm not proposing any API changes in this email; example
(1) does
>> >> >> mention
>> >> >> >> the relocation of FileHelper.java, but that's more to
illustrate
>> >>the
>> >> >> >> benefits of repackaging the plugins.
>> >> >> >>
>> >> >> >> I would think the plugin package change should happen
*for* 3.0,
>> >> >>before
>> >> >> >> people actually start using the plugins all bundled in
one
>> >>package.
>> >> >>  It's
>> >> >> >> not a giant change.
>> >> >> >>
>> >> >> >> On Mon, Jul 15, 2013 at 1:16 PM, Brian LeRoux <b@brian.io>
wrote:
>> >> >> >>
>> >> >> >> > I think all of this makes good sense but will have
to land
>> >>sometime
>> >> >> >> > post 3.0 as that we're pretty much in the final stretch
now
>> >>anyhow.
>> >> >> >> > Which APIs are you specifically proposing we change?
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Mon, Jul 15, 2013 at 9:14 AM, Max Woghiren
>> >><maxw@chromium.org>
>> >> >> wrote:
>> >> >> >> > > On Android, all Cordova plugins are in the package
>> >> >> >> > org.apache.cordova.core.
>> >> >> >> > >  It makes sense to put each plugin into its
own package.
>> >>Aside
>> >> >>from
>> >> >> >> > 3.0's
>> >> >> >> > > conceptual shift into "plugins as completely
individual
>> >>entities"
>> >> >> and
>> >> >> >> the
>> >> >> >> > > fact that plugins aren't really "core", here's
some rationale:
>> >> >> >> > >
>> >> >> >> > >    1. If two plugins have a file with the same
name, we'll
>> >>avoid
>> >> >> >> > >    collisions.  For instance, core Cordova has
>> >>FileHelper.java.
>> >> >>  This
>> >> >> >> is
>> >> >> >> > the
>> >> >> >> > >    wrong place for it in 3.0 and we'd like to
move it to the
>> >> >>plugins
>> >> >> >> > that use
>> >> >> >> > >    it (removing unused methods in each plugin's
version).
>> >> >>However,
>> >> >> >> this
>> >> >> >> > will
>> >> >> >> > >    lead to a collision in apps that use two
of these plugins,
>> >> >>since
>> >> >> >> > they'll
>> >> >> >> > >    both be in the same package.
>> >> >> >> > >    2. All plugin files will be separated into
their packages
>> >>in
>> >> >>your
>> >> >> >> IDE.
>> >> >> >> > >     This makes working on an individual plugin
easier‹you can
>> >>see
>> >> >> the
>> >> >> >> > >    associated files at a glance.  If I'm working
on a plugin
>> >>with
>> >> >> >> > multiple
>> >> >> >> > >    files, I shouldn't have to hunt for related
files to ensure
>> >> >>I'm
>> >> >> not
>> >> >> >> > missing
>> >> >> >> > >    anything.
>> >> >> >> > >    3. Since our plugins will be used as starting
points for
>> >> >> third-party
>> >> >> >> > >    plugins, we won't accidentally encourage
plugin developers
>> >>to
>> >> >>use
>> >> >> >> the
>> >> >> >> > same
>> >> >> >> > >    namespace.
>> >> >> >> > >
>> >> >> >> > > I would propose something like
>> >> >> org.apache.cordova.plugin.<plugin_name>.
>> >> >> >> >
>> >> >> >>
>> >> >>
>> >>
>> >>
>>
>>

Mime
View raw message