I think this is the wrong thread!
On Tue, Jul 30, 2013 at 11:52 AM, Filip Maj <f...@adobe.com> 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" <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>. >>>>> > >> >> >> > >>>>> > >> >> >> >>>>> > >> >> >>>>> > >> >>>>> > >> >>>>> > >>>>> >>> >
