cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Android - Removing the .api namespace
Date Wed, 10 Jul 2013 03:29:58 GMT
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 <bowserj@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 <mmocny@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 <bowserj@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" <agrieve@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 <bowserj@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 <bowserj@gmail.com>
> wrote:
> >> > > > On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve <
> agrieve@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.
> >> > >
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message