cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Android - Removing the .api namespace
Date Wed, 10 Jul 2013 05:33:34 GMT
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" <agrieve@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 <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