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" <b...@brian.io> 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 <f...@adobe.com> wrote: >> We definitely do not follow semver >> >> http://wiki.apache.org/cordova/DeprecationPolicy >> >> >> On 7/16/13 12:15 AM, "David Pfahler" <da...@excellenteasy.com> wrote: >> >>>What or where exactly is the deprecation policy? It's probably not >>>semver<http://semver.org/>, >>>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 <agri...@chromium.org> >>>wrote: >>> >>>> On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux <b...@brian.io> 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 >>>><agri...@chromium.org> >>>> > 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 <f...@adobe.com> wrote: >>>> > > >>>> > >> +1 wait until 3.1. >>>> > >> >>>> > >> +1 add shims for less breakage >>>> > >> >>>> > >> Also worth pointing out that we'll need to add this to the >>>>deprecation >>>> > >> list on the wiki >>>> > >> >>>> > >> On 7/15/13 11:30 AM, "Simon MacDonald" >>>><simon.macdon...@gmail.com> >>>> > 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 <b...@brian.io> >>>>wrote: >>>> > >> > >>>> > >> >> No. You are proposing an API change. A package is most >>>>certainly a >>>> > >> >> part of the API! When we moved from `com.phonegap` to >>>>`org.apache` >>>> > >> >> there was a huge outcry b/c it broke all existing community >>>> plugins. >>>> > >> >> >>>> > >> >> I'm completely open to changing stuff for 3.0 but, again, what >>>> > >> >> specifically are you proposing we change? >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI >>>><anis.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 <b...@brian.io> >>>> wrote: >>>> > >> >> >> >>>> > >> >> >> > I think all of this makes good sense but will have to >>>>land >>>> > sometime >>>> > >> >> >> > post 3.0 as that we're pretty much in the final stretch >>>>now >>>> > anyhow. >>>> > >> >> >> > Which APIs are you specifically proposing we change? >>>> > >> >> >> > >>>> > >> >> >> > >>>> > >> >> >> > >>>> > >> >> >> > On Mon, Jul 15, 2013 at 9:14 AM, Max Woghiren < >>>> > 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. If I'm working on a >>>>plugin >>>> > with >>>> > >> >> >> > multiple >>>> > >> >> >> > > files, I shouldn't have to hunt for related files to >>>> ensure >>>> > >> >>I'm >>>> > >> >> not >>>> > >> >> >> > missing >>>> > >> >> >> > > anything. >>>> > >> >> >> > > 3. Since our plugins will be used as starting points >>>>for >>>> > >> >> third-party >>>> > >> >> >> > > plugins, we won't accidentally encourage plugin >>>> developers >>>> > to >>>> > >> >>use >>>> > >> >> >> the >>>> > >> >> >> > same >>>> > >> >> >> > > namespace. >>>> > >> >> >> > > >>>> > >> >> >> > > I would propose something like >>>> > >> >> org.apache.cordova.plugin.<plugin_name>. >>>> > >> >> >> > >>>> > >> >> >> >>>> > >> >> >>>> > >> >>>> > >> >>>> > >>>> >>
