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