This creates more work one week prior to release. If we didn't have a deadline for this release, I'd be OK with it, but this means that the trivial change would have to happen to all our plugins. Given the time constraint, I think we shouldn't do it.
There's also the fact that our plugin developers hate all change, no matter how reasonable it may seem. That's why I think this should go in 3.1 or 3.2. On Jul 9, 2013 4:12 PM, "Andrew Grieve" <[email protected]> wrote: > :) okay, now let's see if I can convince you Joe. > > What I've done so far was put classes in o.a.c.api that extend the actual > implementations in o.a.c. This is a bit more annoying than I'd like, > because for it work properly, most types must continue to refer to the > o.a.c.api classes, or else you'll get a type errors when dealing with > non-updated code that expects a o.a.c.api class. > > Using a separate namespace (.api) to indicate which methods are a part of > our public API has the huge draw-back of not allowing us to make use of > package-private visibility with the classes in the non-.api namespace. This > is my main motivation for the change. I think Java devs often assume any > symbol that is public is a part of our API, and I think that's pretty > reasonable. Going forward, we should make an effort to convert public > symbols to package-private symbols. This will break any plugin that is > relying on the symbol, but will *not* break any plugins that are not using > the symbol. OTOH, a namespace change, as we're doing here, will break all > plugins. > > So... I'd like to do the complete namespace change now so that when > we privatize symbols that we don't want to be a part of our public API, it > will not break the large majority of plugins. > > If you're not convinced, please say why :) > > > > > > > > > On Tue, Jul 9, 2013 at 5:33 PM, Joe Bowser <[email protected]> wrote: > > > Actually, on second thought, no, let's keep the compatibility classes > > in for now. We may want to keep using this namespace post-3.0. I > > think I misunderstood what was being asked. > > > > On Tue, Jul 9, 2013 at 2:28 PM, Joe Bowser <[email protected]> wrote: > > > On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve <[email protected]> > > wrote: > > >> Want to bring this up again. > > >> > > >> There was a bit of discussion on the bug: > > >> https://issues.apache.org/jira/browse/CB-4038 > > >> > > >> I've already gone ahead with creating backward-compatiblity classes in > > the > > >> .api namespace, but I think it would be better to just delete them. > > >> > > >> Main points in favour: > > >> 1. For 3.0, people will need to do some work to their plugins anyways > > (add > > >> plugin.xml + refactor their JS into modules comes to mind) > > >> 2. The change to plugins is trivial. Just replace all occurrences of > > >> "import org.apache.cordova.api" with "import org.apache.cordova". > > >> > > > > > > I'm OK with it for now, only because we don't have the time to > > > formalize the Android Plugin API. I would have liked to keep the api > > > separation but perhaps we can revisit this 3.1 or 3.2. > > >
