Here's my thinking: - For 3.0, we're going to do a big push to ask devs to update their plugins, so we should put some effort into providing a clear set of supported APIs on the Java side that they should code against. - Right now we have a lot of public methods, and I think many of them are only public because we have two namespaces (one with .api and one without). - I'd like to make as many symbols non-public before new plugins come along and start using them (e.g. PluginManager. clearPluginObjects() shouldn't be a public API).
Doesn't feel that last minute to me... we haven't even shipped 2.9 yet. On Mon, Jun 24, 2013 at 11:00 AM, Joe Bowser <bows...@gmail.com> wrote: > Can we do this post-3.0? This change seems a bit last minute. > On Jun 24, 2013 7:57 AM, "Andrew Grieve" <agri...@chromium.org> wrote: > > > On the Java side of things, there are a few files in the > > org.apache.cordova.api namespace. > > > > I'd like to remove this namespace and put all Cordova classes under > > org.apache.cordova so that we can use package-private visibility where > > appropriate. > > > > For backwards compatibility, we can use the same trick of having an empty > > class extend the moved one sitting around in the old namespace. > > >
