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