Re: Plugin packages on Android

[Joe Bowser]

I think this is the wrong thread!

On Tue, Jul 30, 2013 at 11:52 AM, Filip Maj  wrote:
> It seems like removal of the "org.apache.cordova.api" namespace happened
> in 3.0 anyways, even though there was no consensus on this thread for it,
> with the big one being CordovaPlugin (moved to org.apache.cordova), and no
> shims were put in place.
>
> No surprise, users are confused and angry.
>
> I would think at a minimum we would have put in a deprecation notice, let
> alone keep shims around to support users for a few months.
>
> I think this issue is big enough to warrant releasing a 3.0.1.
>
> The change was also not documented which I've filed as CB-4454 [1].
>
> I'm not pleased about this commit landing [2].
>
> [1] https://issues.apache.org/jira/browse/CB-4454
> [2]
> https://github.com/apache/cordova-android/commit/b5c3ac605ac2d771a56dadc3a0
> 6cd120976f9a99
>
> On 7/16/13 9:18 AM, "Brian LeRoux"  wrote:
>
>>ftr phonegap predates semver which is basically a reaction to ruby's
>>globally installed package legacy
>>
>>that said, its a neat system
>>
>>On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj  wrote:
>>> We definitely do not follow semver
>>>
>>> http://wiki.apache.org/cordova/DeprecationPolicy
>>>
>>>
>>> On 7/16/13 12:15 AM, "David Pfahler"  wrote:
>>>
What or where exactly is the deprecation policy? It's probably not
semver,
because breaking changes need a major version update in semver. Hence,
breaking these plugins would require 4.0, not 3.1. But I guess this is
just
not how you have set it up.


On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve 
wrote:

> On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:
>
> > A package namespace is not a part of the API? Are we saying we in
> > Cordova draw the semantic line at a method signature? (Its certainly
> > not a normal view on what defines an API. Anyhow! Super not
> > important.)
> >
> > One more time! Specifics. What packages are changing in precisely
>what
> > files? Right now we're discussing a completely undefined scope in
> > light of an obviously standard best practice.
> >
> >
> >
> > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve
>
> > wrote:
> > > -1 to shims. A plugin's java package name shouldn't be considered
>a
> part
> > 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.
> > Those
> > > 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?
> >
> ^^ this is the specifics. pkg stmts for plugin files + refs in
>plugin.xml.
> This is different from the phonegap->cordova change because a) no core
> files are changed and b) we've already changed the pkg name by adding
> ".core"
>
>
> > >
> > >
> > >
> > >
> > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  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
>deprecation
> > >> list on the wiki
> > >>
> > >> On 7/15/13 11:30 AM, "Simon MacDonald"
>
> > wrote:
> > >>
> > >> >The reason things broke back then was we didn't leave in shims
>to
> point
> > >> >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 
>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
> >
> > >> >>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.
> > >> >> >
> > >>

Re: Plugin packages on Android

[Filip Maj]

It seems like removal of the "org.apache.cordova.api" namespace happened
in 3.0 anyways, even though there was no consensus on this thread for it,
with the big one being CordovaPlugin (moved to org.apache.cordova), and no
shims were put in place.

No surprise, users are confused and angry.

I would think at a minimum we would have put in a deprecation notice, let
alone keep shims around to support users for a few months.

I think this issue is big enough to warrant releasing a 3.0.1.

The change was also not documented which I've filed as CB-4454 [1].

I'm not pleased about this commit landing [2].

[1] https://issues.apache.org/jira/browse/CB-4454
[2] 
https://github.com/apache/cordova-android/commit/b5c3ac605ac2d771a56dadc3a0
6cd120976f9a99

On 7/16/13 9:18 AM, "Brian LeRoux"  wrote:

>ftr phonegap predates semver which is basically a reaction to ruby's
>globally installed package legacy
>
>that said, its a neat system
>
>On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj  wrote:
>> We definitely do not follow semver
>>
>> http://wiki.apache.org/cordova/DeprecationPolicy
>>
>>
>> On 7/16/13 12:15 AM, "David Pfahler"  wrote:
>>
>>>What or where exactly is the deprecation policy? It's probably not
>>>semver,
>>>because breaking changes need a major version update in semver. Hence,
>>>breaking these plugins would require 4.0, not 3.1. But I guess this is
>>>just
>>>not how you have set it up.
>>>
>>>
>>>On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve 
>>>wrote:
>>>
 On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:

 > A package namespace is not a part of the API? Are we saying we in
 > Cordova draw the semantic line at a method signature? (Its certainly
 > not a normal view on what defines an API. Anyhow! Super not
 > important.)
 >
 > One more time! Specifics. What packages are changing in precisely
what
 > files? Right now we're discussing a completely undefined scope in
 > light of an obviously standard best practice.
 >
 >
 >
 > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve

 > wrote:
 > > -1 to shims. A plugin's java package name shouldn't be considered
a
 part
 > 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.
 > Those
 > > 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?
 >
 ^^ this is the specifics. pkg stmts for plugin files + refs in
plugin.xml.
 This is different from the phonegap->cordova change because a) no core
 files are changed and b) we've already changed the pkg name by adding
 ".core"


 > >
 > >
 > >
 > >
 > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  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
deprecation
 > >> list on the wiki
 > >>
 > >> On 7/15/13 11:30 AM, "Simon MacDonald"

 > wrote:
 > >>
 > >> >The reason things broke back then was we didn't leave in shims
to
 point
 > >> >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 
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
>>> >
 > >> >>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 <
 m...@chromium.org>
 > >> >> wrote:
 > >> >> >
 > >> >> >> I'm not proposing any API changes in this email; example
(1)
 does
 > >> >> mention
 > >> >> 

Re: Plugin packages on Android

[Brian LeRoux]

ftr phonegap predates semver which is basically a reaction to ruby's
globally installed package legacy

that said, its a neat system

On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj  wrote:
> We definitely do not follow semver
>
> http://wiki.apache.org/cordova/DeprecationPolicy
>
>
> On 7/16/13 12:15 AM, "David Pfahler"  wrote:
>
>>What or where exactly is the deprecation policy? It's probably not
>>semver,
>>because breaking changes need a major version update in semver. Hence,
>>breaking these plugins would require 4.0, not 3.1. But I guess this is
>>just
>>not how you have set it up.
>>
>>
>>On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve 
>>wrote:
>>
>>> On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:
>>>
>>> > A package namespace is not a part of the API? Are we saying we in
>>> > Cordova draw the semantic line at a method signature? (Its certainly
>>> > not a normal view on what defines an API. Anyhow! Super not
>>> > important.)
>>> >
>>> > One more time! Specifics. What packages are changing in precisely what
>>> > files? Right now we're discussing a completely undefined scope in
>>> > light of an obviously standard best practice.
>>> >
>>> >
>>> >
>>> > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve 
>>> > wrote:
>>> > > -1 to shims. A plugin's java package name shouldn't be considered a
>>> part
>>> > 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.
>>> > Those
>>> > > 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?
>>> >
>>> ^^ this is the specifics. pkg stmts for plugin files + refs in
>>>plugin.xml.
>>> This is different from the phonegap->cordova change because a) no core
>>> files are changed and b) we've already changed the pkg name by adding
>>> ".core"
>>>
>>>
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  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
>>>deprecation
>>> > >> list on the wiki
>>> > >>
>>> > >> On 7/15/13 11:30 AM, "Simon MacDonald" 
>>> > wrote:
>>> > >>
>>> > >> >The reason things broke back then was we didn't leave in shims to
>>> point
>>> > >> >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  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
> >
>>> > >> >>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 <
>>> m...@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 
>>> 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 <
>>> > m...@chromium.org>
>>> > >> >> wrote:
>>> > >> >> >> > > On Android, all Cordova plugins are 

Re: Plugin packages on Android

[Filip Maj]

We definitely do not follow semver

http://wiki.apache.org/cordova/DeprecationPolicy


On 7/16/13 12:15 AM, "David Pfahler"  wrote:

>What or where exactly is the deprecation policy? It's probably not
>semver,
>because breaking changes need a major version update in semver. Hence,
>breaking these plugins would require 4.0, not 3.1. But I guess this is
>just
>not how you have set it up.
>
>
>On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve 
>wrote:
>
>> On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:
>>
>> > A package namespace is not a part of the API? Are we saying we in
>> > Cordova draw the semantic line at a method signature? (Its certainly
>> > not a normal view on what defines an API. Anyhow! Super not
>> > important.)
>> >
>> > One more time! Specifics. What packages are changing in precisely what
>> > files? Right now we're discussing a completely undefined scope in
>> > light of an obviously standard best practice.
>> >
>> >
>> >
>> > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve 
>> > wrote:
>> > > -1 to shims. A plugin's java package name shouldn't be considered a
>> part
>> > 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.
>> > Those
>> > > 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?
>> >
>> ^^ this is the specifics. pkg stmts for plugin files + refs in
>>plugin.xml.
>> This is different from the phonegap->cordova change because a) no core
>> files are changed and b) we've already changed the pkg name by adding
>> ".core"
>>
>>
>> > >
>> > >
>> > >
>> > >
>> > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  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
>>deprecation
>> > >> list on the wiki
>> > >>
>> > >> On 7/15/13 11:30 AM, "Simon MacDonald" 
>> > wrote:
>> > >>
>> > >> >The reason things broke back then was we didn't leave in shims to
>> point
>> > >> >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  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
>>> >
>> > >> >>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 <
>> m...@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 
>> 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 <
>> > m...@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 are

Re: Plugin packages on Android

[David Pfahler]

What or where exactly is the deprecation policy? It's probably not
semver,
because breaking changes need a major version update in semver. Hence,
breaking these plugins would require 4.0, not 3.1. But I guess this is just
not how you have set it up.


On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve  wrote:

> On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:
>
> > A package namespace is not a part of the API? Are we saying we in
> > Cordova draw the semantic line at a method signature? (Its certainly
> > not a normal view on what defines an API. Anyhow! Super not
> > important.)
> >
> > One more time! Specifics. What packages are changing in precisely what
> > files? Right now we're discussing a completely undefined scope in
> > light of an obviously standard best practice.
> >
> >
> >
> > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve 
> > wrote:
> > > -1 to shims. A plugin's java package name shouldn't be considered a
> part
> > 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.
> > Those
> > > 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?
> >
> ^^ this is the specifics. pkg stmts for plugin files + refs in plugin.xml.
> This is different from the phonegap->cordova change because a) no core
> files are changed and b) we've already changed the pkg name by adding
> ".core"
>
>
> > >
> > >
> > >
> > >
> > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  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 deprecation
> > >> list on the wiki
> > >>
> > >> On 7/15/13 11:30 AM, "Simon MacDonald" 
> > wrote:
> > >>
> > >> >The reason things broke back then was we didn't leave in shims to
> point
> > >> >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  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  >
> > >> >>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 <
> m...@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 
> 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 <
> > m...@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
> > >> >> >> > >

Re: Plugin packages on Android

[Andrew Grieve]

On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:

> A package namespace is not a part of the API? Are we saying we in
> Cordova draw the semantic line at a method signature? (Its certainly
> not a normal view on what defines an API. Anyhow! Super not
> important.)
>
> One more time! Specifics. What packages are changing in precisely what
> files? Right now we're discussing a completely undefined scope in
> light of an obviously standard best practice.
>
>
>
> On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve 
> wrote:
> > -1 to shims. A plugin's java package name shouldn't be considered a part
> 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.
> Those
> > 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?
>
^^ this is the specifics. pkg stmts for plugin files + refs in plugin.xml.
This is different from the phonegap->cordova change because a) no core
files are changed and b) we've already changed the pkg name by adding
".core"


> >
> >
> >
> >
> > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  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 deprecation
> >> list on the wiki
> >>
> >> On 7/15/13 11:30 AM, "Simon MacDonald" 
> wrote:
> >>
> >> >The reason things broke back then was we didn't leave in shims to point
> >> >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  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 
> >> >>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 
> >> >> 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  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 <
> m...@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.

Re: Plugin packages on Android

[Brian LeRoux]

A package namespace is not a part of the API? Are we saying we in
Cordova draw the semantic line at a method signature? (Its certainly
not a normal view on what defines an API. Anyhow! Super not
important.)

One more time! Specifics. What packages are changing in precisely what
files? Right now we're discussing a completely undefined scope in
light of an obviously standard best practice.



On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve  wrote:
> -1 to shims. A plugin's java package name shouldn't be considered a part 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. Those
> 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  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 deprecation
>> list on the wiki
>>
>> On 7/15/13 11:30 AM, "Simon MacDonald"  wrote:
>>
>> >The reason things broke back then was we didn't leave in shims to point
>> >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  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 
>> >>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 
>> >> 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  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 
>> >> 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..
>> >> >> >
>> >> >>
>> >>
>>
>>

Re: Plugin packages on Android

[Joe Bowser]

OK, Test killed.  I get the same thing on this end.  Let's close that bug off!

On Mon, Jul 15, 2013 at 2:04 PM, Joe Bowser  wrote:
> I'm going to kill that test! This is the Cordova project, not JQMobile.
>
> On Mon, Jul 15, 2013 at 1:45 PM, Andrew Grieve  wrote:
>> Awesome. So for UriResolvers, I just checked in another revision today, and
>> I'm not happy with it and all that's left is documentation. If you wanted
>> to do a code review on it, that would be cool too.
>>
>> I also ran the junit tests (as of an hour ago), and the only test that
>> fails is the JQMTabTest, which had an exception about missing a manifest
>> permission for simulating events. Trying to add that permission gave me an
>> error that said only system apps are allowed to have the permission. Is
>> that what you're seeing?
>>
>>
>> On Mon, Jul 15, 2013 at 3:58 PM, Joe Bowser  wrote:
>>
>>> 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 
>>> wrote:
>>> > 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  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"  wrote:
>>> >>
>>> >> >-1 to shims. A plugin's java package name shouldn't be considered a
>>> part
>>> >> >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.
>>> Those
>>> >> >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  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
>>> deprecation
>>> >> >> list on the wiki
>>> >> >>
>>> >> >> On 7/15/13 11:30 AM, "Simon MacDonald" 
>>> >> >>wrote:
>>> >> >>
>>> >> >> >The reason things broke back then was we didn't leave in shims to
>>> point
>>> >> >> >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  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.ka...@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 <
>>> m...@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.
>>> >

Re: Plugin packages on Android

[Joe Bowser]

I'm going to kill that test! This is the Cordova project, not JQMobile.

On Mon, Jul 15, 2013 at 1:45 PM, Andrew Grieve  wrote:
> Awesome. So for UriResolvers, I just checked in another revision today, and
> I'm not happy with it and all that's left is documentation. If you wanted
> to do a code review on it, that would be cool too.
>
> I also ran the junit tests (as of an hour ago), and the only test that
> fails is the JQMTabTest, which had an exception about missing a manifest
> permission for simulating events. Trying to add that permission gave me an
> error that said only system apps are allowed to have the permission. Is
> that what you're seeing?
>
>
> On Mon, Jul 15, 2013 at 3:58 PM, Joe Bowser  wrote:
>
>> 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 
>> wrote:
>> > 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  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"  wrote:
>> >>
>> >> >-1 to shims. A plugin's java package name shouldn't be considered a
>> part
>> >> >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.
>> Those
>> >> >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  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
>> deprecation
>> >> >> list on the wiki
>> >> >>
>> >> >> On 7/15/13 11:30 AM, "Simon MacDonald" 
>> >> >>wrote:
>> >> >>
>> >> >> >The reason things broke back then was we didn't leave in shims to
>> point
>> >> >> >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  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.ka...@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 <
>> m...@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 
>> wrote:
>> >> >> >> >>
>> >> >> >> >> > I think all of this makes good sense but will have to land
>> >> >>sometime
>> >> >> >> >> > pos

Re: Plugin packages on Android

[Andrew Grieve]

Awesome. So for UriResolvers, I just checked in another revision today, and
I'm not happy with it and all that's left is documentation. If you wanted
to do a code review on it, that would be cool too.

I also ran the junit tests (as of an hour ago), and the only test that
fails is the JQMTabTest, which had an exception about missing a manifest
permission for simulating events. Trying to add that permission gave me an
error that said only system apps are allowed to have the permission. Is
that what you're seeing?


On Mon, Jul 15, 2013 at 3:58 PM, Joe Bowser  wrote:

> 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 
> wrote:
> > 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  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"  wrote:
> >>
> >> >-1 to shims. A plugin's java package name shouldn't be considered a
> part
> >> >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.
> Those
> >> >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  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
> deprecation
> >> >> list on the wiki
> >> >>
> >> >> On 7/15/13 11:30 AM, "Simon MacDonald" 
> >> >>wrote:
> >> >>
> >> >> >The reason things broke back then was we didn't leave in shims to
> point
> >> >> >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  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.ka...@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 <
> m...@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 
> 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
> >> >>
> >> >> >> wr

Re: Plugin packages on Android

[Joe Bowser]

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  wrote:
> 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  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"  wrote:
>>
>> >-1 to shims. A plugin's java package name shouldn't be considered a part
>> >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. Those
>> >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  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 deprecation
>> >> list on the wiki
>> >>
>> >> On 7/15/13 11:30 AM, "Simon MacDonald" 
>> >>wrote:
>> >>
>> >> >The reason things broke back then was we didn't leave in shims to point
>> >> >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  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 
>> >> >>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 
>> >> >> 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  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
>> >>
>> >> >> 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,
>> >> >>

Re: Plugin packages on Android

[Andrew Grieve]

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  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"  wrote:
>
> >-1 to shims. A plugin's java package name shouldn't be considered a part
> >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. Those
> >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  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 deprecation
> >> list on the wiki
> >>
> >> On 7/15/13 11:30 AM, "Simon MacDonald" 
> >>wrote:
> >>
> >> >The reason things broke back then was we didn't leave in shims to point
> >> >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  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 
> >> >>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 
> >> >> 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  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
> >>
> >> >> 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.
> >

Re: Plugin packages on Android

[Filip Maj]

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"  wrote:

>-1 to shims. A plugin's java package name shouldn't be considered a part
>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. Those
>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  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 deprecation
>> list on the wiki
>>
>> On 7/15/13 11:30 AM, "Simon MacDonald" 
>>wrote:
>>
>> >The reason things broke back then was we didn't leave in shims to point
>> >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  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 
>> >>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 
>> >> 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  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
>>
>> >> 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..
>> >> >> >
>> >> >>
>> >>
>>
>>

Re: Plugin packages on Android

[Joe Bowser]

On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve  wrote:
> -1 to shims. A plugin's java package name shouldn't be considered a part 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. Those
> use plugin IDs, not java namespaces.

If this is really true, then I don't see why we don't wait until the
next release.

> 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?

I think we have enough work already without adding this extra polish.
This is the only release where we have a deadline, and I think that
adding this will make us miss that deadline.

Re: Plugin packages on Android

[Andrew Grieve]

-1 to shims. A plugin's java package name shouldn't be considered a part 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. Those
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  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 deprecation
> list on the wiki
>
> On 7/15/13 11:30 AM, "Simon MacDonald"  wrote:
>
> >The reason things broke back then was we didn't leave in shims to point
> >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  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 
> >>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 
> >> 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  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 
> >> 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..
> >> >> >
> >> >>
> >>
>
>

Re: Plugin packages on Android

[Filip Maj]

+1 wait until 3.1.

+1 add shims for less breakage

Also worth pointing out that we'll need to add this to the deprecation
list on the wiki

On 7/15/13 11:30 AM, "Simon MacDonald"  wrote:

>The reason things broke back then was we didn't leave in shims to point
>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  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 
>>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 
>> 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  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 
>> 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..
>> >> >
>> >>
>>

Re: Plugin packages on Android

[Simon MacDonald]

The reason things broke back then was we didn't leave in shims to point
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  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  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 
> 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  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 
> 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..
> >> >
> >>
>

Re: Plugin packages on Android

[Brian LeRoux]

Yea, to be clear, I'm in favor of namespaces. They're a honking good idea.

But lets push this to 3.1 and leave shims around until 3.5/3.6 as per
our deprecation policy.


On Mon, Jul 15, 2013 at 11:16 AM, Steven Gill  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  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  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  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 
>> 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 
>> >> 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  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 
>> >> 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..
>> >> >> >
>> >> >>
>> >>
>>

Re: Plugin packages on Android

[Anis KADRI]

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 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  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 
> 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  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 
> > 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 
> > >> 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  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  >
> > >> 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..
> > >> >> >
> > >> >>
> > >>
> >
>

Re: Plugin packages on Android

[Steven Gill]

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  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  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  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 
> 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 
> >> 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  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 
> >> 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..
> >> >> >
> >> >>
> >>
>

Re: Plugin packages on Android

[Joe Bowser]

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  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  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  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 
>> 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  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 
>> 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..
>> >> >
>> >>
>>

Re: Plugin packages on Android

[Max Woghiren]

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  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  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 
> 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  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 
> 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..
> >> >
> >>
>

Re: Plugin packages on Android

[Brian LeRoux]

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  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  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  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  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..
>> >
>>

Re: Plugin packages on Android

[Anis KADRI]

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  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  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  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..
> >
>

Re: Plugin packages on Android

[Max Woghiren]

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  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  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..
>

Re: Plugin packages on Android

[Brian LeRoux]

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  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 packages on Android

[Max Woghiren]

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..