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 <stevengil...@gmail.com> 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 <bows...@gmail.com> 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 <m...@chromium.org> wrote: >> > I am proposing we change all of the Android plugins in Cordova 3.0 to >> > belong in individual packages. >> > >> > For instance, the FileTransfer plugin, which currently exists in the >> > org.apache.cordova.core package, should be moved to, say, >> > org.apache.cordova.plugin.filetransfer. Every plugin should be moved >> > accordingly. >> > >> > I don't expect much (or any) outcry, since 3.0 isn't released yet. This >> is >> > a 3.0-specific change. >> > >> > >> > On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux <b...@brian.io> wrote: >> > >> >> No. You are proposing an API change. A package is most certainly a >> >> part of the API! When we moved from `com.phonegap` to `org.apache` >> >> there was a huge outcry b/c it broke all existing community plugins. >> >> >> >> I'm completely open to changing stuff for 3.0 but, again, what >> >> specifically are you proposing we change? >> >> >> >> >> >> >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI <anis.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>. >> >> >> > >> >> >> >> >> >>
