Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of bowserj@gmail.com designates
 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABiQX1V_q0d2TVv+_mJ39keJgBtJtZtFetmeeC9b966wm8pmXg@mail.gmail.com>
References: 
 <CABiQX1UtNpKKgprkZFPh7ZmzbvRyx1wRecB4NKKhPxQct83rgg@mail.gmail.com>
	<CE099A3E.22682%fil@adobe.com>
	<CABiQX1V_q0d2TVv+_mJ39keJgBtJtZtFetmeeC9b966wm8pmXg@mail.gmail.com>
Date: Mon, 15 Jul 2013 12:58:42 -0700
Message-ID: 
 <CAOBL_k7tWw_1tPYiwTOMhahAHWM0dVvL_RQjdyKgxGiNHNLAEQ@mail.gmail.com>
Subject: Re: Plugin packages on Android
From: Joe Bowser <bowserj@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I feel like Android is in good shape for the most part, but I can't
say the same about the plugins or the CLI that I'm currently using to
load them, since I haven't tested today's changes yet.  That being
said, I think you guys have some open issues still, like the
UriResolvers, and I did see a jUnit test fail when I was in the tests
directory working with Robotium (which now works with Cordova), which
is why I'm wondering why we're talking about polish.


On Mon, Jul 15, 2013 at 12:46 PM, Andrew Grieve <agrieve@chromium.org> wrot=
e:
> Joe - what non-polish items are left for Android? If you're feeling like
> you have too much to do this week, maybe you can delegate some tasks?
>
>
> On Mon, Jul 15, 2013 at 3:27 PM, Filip Maj <fil@adobe.com> wrote:
>
>> I think what you're saying Andrew is true under the assumption that
>> plugins are ONLY consumed via the JS api. I'm not sure whether that
>> assumption is correct in all cases.
>>
>> In any case, clarifying this point (dependency "scope" we could call it,
>> perhaps?) seems like a good idea.
>>
>> On 7/15/13 12:14 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>>
>> >-1 to shims. A plugin's java package name shouldn't be considered a par=
t
>> >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. Th=
ose
>> >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 deprecatio=
n
>> >> 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 po=
int
>> >> >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 plugin=
s.
>> >> >>
>> >> >> 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.or=
g>
>> >> >> wrote:
>> >> >> >
>> >> >> >> I'm not proposing any API changes in this email; example (1) do=
es
>> >> >> mention
>> >> >> >> the relocation of FileHelper.java, but that's more to illustrat=
e
>> >>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> wrot=
e:
>> >> >> >>
>> >> >> >> > 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 rationa=
le:
>> >> >> >> > >
>> >> >> >> > >    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 th=
e
>> >> >>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 plugin=
s,
>> >> >>since
>> >> >> >> > they'll
>> >> >> >> > >    both be in the same package.
>> >> >> >> > >    2. All plugin files will be separated into their package=
s
>> >>in
>> >> >>your
>> >> >> >> IDE.
>> >> >> >> > >     This makes working on an individual plugin easier=E2=80=
=B9you can
>> >>see
>> >> >> the
>> >> >> >> > >    associated files at a glance.  If I'm working on a plugi=
n
>> >>with
>> >> >> >> > multiple
>> >> >> >> > >    files, I shouldn't have to hunt for related files to ens=
ure
>> >> >>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 develope=
rs
>> >>to
>> >> >>use
>> >> >> >> the
>> >> >> >> > same
>> >> >> >> > >    namespace.
>> >> >> >> > >
>> >> >> >> > > I would propose something like
>> >> >> org.apache.cordova.plugin.<plugin_name>.
>> >> >> >> >
>> >> >> >>
>> >> >>
>> >>
>> >>
>>
>>