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