cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Plugin packages on Android
Date Mon, 15 Jul 2013 20:45:55 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message