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 19:14:48 GMT
-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