cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Plugin packages on Android
Date Mon, 15 Jul 2013 18:14:11 GMT
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
View raw message