Fair enough. We'll make a clean break and see what happens. I don't think it'll be as bad as last year, that being said nothing could be worst than how last year's major release went. On Jul 9, 2013 8:30 PM, "Andrew Grieve" <agri...@chromium.org> wrote:
> I agree with you that developers that want to use old plugins are going to > be annoyed that they won't work out-of-the-box with 3.0. You raise very > good points about big changes they'll need to do to update plugins (Plugin > -> CordovaPlugin & a plugin.xml file). If they manage to do this though, I > don't think tweaking import statements is going to trip them up. > > Better to have them change imports while they are changing other things, > then to do this in 3.1 and tell them that their 3.0 compatible plugins need > updating again. We're just talking a simple search & replace. Eclipse will > underline it and suggest the correct fix. > > You speculate people will hate our 3.0 plugin changes? I speculate the > majority are going think it's great! :) > > > > > On Tue, Jul 9, 2013 at 11:06 PM, Joe Bowser <bows...@gmail.com> wrote: > > > OK, so I'll put myself in the plugin developers shoes. (The ones that > > work on shipping an app instead of working on cordova.) > > > > So far, we've asked plugin developers to migrate from the old-style > > plugins to CordovaPlugin so that their plugins will work with 3.0.0. > > Many plugin developers have already done that. So, these people, > > assuming that they've done the right thing and upgraded everything to > > 3.0.0 will try and load their plugins the old fashioned, non-plugman > > way into their application and see that it doesn't work. They'll see > > that the namespace changed, change it, and then blame me for all their > > problems and talk about how crappy it is that they had to change one > > damn import. Or worse, there will be the people who can't write Java > > at all and can't manage to do a find/replace on it. > > > > We're already going to have a heavy backlash from users who find that > > their old Cordova plugins that are using the old Plugin API that we > > had to shim in for 2.x are no longer going to work, this will > > literally be more salt on those wounds. > > > > If someone wants to be the face of these change in the community, I'm > > OK with it. I just know that from last year, being the guy who broke > > all the plugins in Cordova/PhoneGap is not the guy that you want to > > be, no matter how cool your new feature is. > > > > Joe > > > > On Tue, Jul 9, 2013 at 6:33 PM, Michal Mocny <mmo...@chromium.org> > wrote: > > > I'de have to disagree with that argument, Joe. I think Andrew did the > > work > > > for core plugins, and there should be no published external plugins > using > > > the new 3.0 plugin structure yet, right? > > > > > > Are we intending to not break compatibility with some hypothetical > > external > > > plugin dev who used a pre-release tool, yet isn't willing to a single > > > string find-and-replace? Is there a even a single concrete example > here, > > > or is this just speculation? > > > > > > -Michal > > > > > > > > > On Tue, Jul 9, 2013 at 7:22 PM, Joe Bowser <bows...@gmail.com> wrote: > > > > > >> 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" <agri...@chromium.org> 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 <bows...@gmail.com> > 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 <bows...@gmail.com> > > wrote: > > >> > > > On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve < > > agri...@chromium.org > > >> > > > >> > > 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. > > >> > > > > >> > > > >> > > >
