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 21:16:58 GMT
OK, Test killed.  I get the same thing on this end.  Let's close that bug off!

On Mon, Jul 15, 2013 at 2:04 PM, Joe Bowser <bowserj@gmail.com> wrote:
> I'm going to kill that test! This is the Cordova project, not JQMobile.
>
> On Mon, Jul 15, 2013 at 1:45 PM, Andrew Grieve <agrieve@chromium.org> wrote:
>> Awesome. So for UriResolvers, I just checked in another revision today, and
>> I'm not happy with it and all that's left is documentation. If you wanted
>> to do a code review on it, that would be cool too.
>>
>> I also ran the junit tests (as of an hour ago), and the only test that
>> fails is the JQMTabTest, which had an exception about missing a manifest
>> permission for simulating events. Trying to add that permission gave me an
>> error that said only system apps are allowed to have the permission. Is
>> that what you're seeing?
>>
>>
>> On Mon, Jul 15, 2013 at 3:58 PM, Joe Bowser <bowserj@gmail.com> wrote:
>>
>>> 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