cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Woghiren <m...@chromium.org>
Subject Re: Plugin packages on Android
Date Mon, 15 Jul 2013 17:33:26 GMT
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