cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Plugin packages on Android
Date Mon, 15 Jul 2013 17:43:42 GMT
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