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