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 03:06:53 GMT
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
View raw message