-1 to shims. A plugin's java package name shouldn't be considered a part of its API. That's why there is a mapping in the config.xml.
Shouldn't have to change any require() statements, or any JS at all. Those use plugin IDs, not java namespaces. Replace-all on the package statement at the top of the file, and change the reference in plugin.xml. I'd put this change in the "polish" category. That's what we should be doing now, no? On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj <[email protected]> wrote: > +1 wait until 3.1. > > +1 add shims for less breakage > > Also worth pointing out that we'll need to add this to the deprecation > list on the wiki > > On 7/15/13 11:30 AM, "Simon MacDonald" <[email protected]> wrote: > > >The reason things broke back then was we didn't leave in shims to point > >anyone compiling against com.phonegap.api to org.apache.cordova.api. That > >was quickly corrected. > > > >I agree with the package name change but with 3.0 shipping this week(?). > >It > >should probably wait until the next version. > > > > > >Simon Mac Donald > >http://hi.im/simonmacdonald > > > > > >On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux <[email protected]> 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 <[email protected]> > >>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 <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> > >> 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>. > >> >> > > >> >> > >> > >
