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 18:22:11 GMT
If you guys are uncomfortable with it, it should wait. I don't think it's a
huge priority anyway.

On Mon, Jul 15, 2013 at 11:16 AM, Steven Gill <stevengill97@gmail.com>wrote:

> This will involve changing all of the plugin.xml files as well as any
> require statements in the javascript files of those plugins. Seems like a
> lot of work to squeeze in for 3.0
>
>
> On Mon, Jul 15, 2013 at 11:14 AM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > Can we NOT do this now?  We have in reality three days of dev left
> > before we release 3.0.  We don't have time for these last minute
> > changes, no matter how trivial.
> >
> > On Mon, Jul 15, 2013 at 11:12 AM, Max Woghiren <maxw@chromium.org>
> wrote:
> > > I am proposing we change all of the Android plugins in Cordova 3.0 to
> > > belong in individual packages.
> > >
> > > For instance, the FileTransfer plugin, which currently exists in the
> > > org.apache.cordova.core package, should be moved to, say,
> > > org.apache.cordova.plugin.filetransfer.  Every plugin should be moved
> > > accordingly.
> > >
> > > I don't expect much (or any) outcry, since 3.0 isn't released yet.
>  This
> > is
> > > a 3.0-specific change.
> > >
> > >
> > > 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