cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Plugin packages on Android
Date Tue, 30 Jul 2013 18:58:40 GMT
I think this is the wrong thread!

On Tue, Jul 30, 2013 at 11:52 AM, Filip Maj <fil@adobe.com> wrote:
> It seems like removal of the "org.apache.cordova.api" namespace happened
> in 3.0 anyways, even though there was no consensus on this thread for it,
> with the big one being CordovaPlugin (moved to org.apache.cordova), and no
> shims were put in place.
>
> No surprise, users are confused and angry.
>
> I would think at a minimum we would have put in a deprecation notice, let
> alone keep shims around to support users for a few months.
>
> I think this issue is big enough to warrant releasing a 3.0.1.
>
> The change was also not documented which I've filed as CB-4454 [1].
>
> I'm not pleased about this commit landing [2].
>
> [1] https://issues.apache.org/jira/browse/CB-4454
> [2]
> https://github.com/apache/cordova-android/commit/b5c3ac605ac2d771a56dadc3a0
> 6cd120976f9a99
>
> On 7/16/13 9:18 AM, "Brian LeRoux" <b@brian.io> wrote:
>
>>ftr phonegap predates semver which is basically a reaction to ruby's
>>globally installed package legacy
>>
>>that said, its a neat system
>>
>>On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj <fil@adobe.com> wrote:
>>> We definitely do not follow semver
>>>
>>> http://wiki.apache.org/cordova/DeprecationPolicy
>>>
>>>
>>> On 7/16/13 12:15 AM, "David Pfahler" <david@excellenteasy.com> wrote:
>>>
>>>>What or where exactly is the deprecation policy? It's probably not
>>>>semver<http://semver.org/>,
>>>>because breaking changes need a major version update in semver. Hence,
>>>>breaking these plugins would require 4.0, not 3.1. But I guess this is
>>>>just
>>>>not how you have set it up.
>>>>
>>>>
>>>>On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve <agrieve@chromium.org>
>>>>wrote:
>>>>
>>>>> On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux <b@brian.io> wrote:
>>>>>
>>>>> > A package namespace is not a part of the API? Are we saying we in
>>>>> > Cordova draw the semantic line at a method signature? (Its certainly
>>>>> > not a normal view on what defines an API. Anyhow! Super not
>>>>> > important.)
>>>>> >
>>>>> > One more time! Specifics. What packages are changing in precisely
>>>>>what
>>>>> > files? Right now we're discussing a completely undefined scope in
>>>>> > light of an obviously standard best practice.
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve
>>>>><agrieve@chromium.org>
>>>>> > wrote:
>>>>> > > -1 to shims. A plugin's java package name shouldn't be considered
>>>>>a
>>>>> part
>>>>> > of
>>>>> > > its API. That's why there is a mapping in the config.xml.
>>>>> > >
>>>>> > > Shouldn't have to change any require() statements, or any JS
at
>>>>>all.
>>>>> > Those
>>>>> > > use plugin IDs, not java namespaces.
>>>>> > >
>>>>> > > Replace-all on the package statement at the top of the file,
and
>>>>>change
>>>>> > the
>>>>> > > reference in plugin.xml. I'd put this change in the "polish"
>>>>>category.
>>>>> > > That's what we should be doing now, no?
>>>>> >
>>>>> ^^ this is the specifics. pkg stmts for plugin files + refs in
>>>>>plugin.xml.
>>>>> This is different from the phonegap->cordova change because a) no
core
>>>>> files are changed and b) we've already changed the pkg name by adding
>>>>> ".core"
>>>>>
>>>>>
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj <fil@adobe.com>
wrote:
>>>>> > >
>>>>> > >> +1 wait until 3.1.
>>>>> > >>
>>>>> > >> +1 add shims for less breakage
>>>>> > >>
>>>>> > >> Also worth pointing out that we'll need to add this to
the
>>>>>deprecation
>>>>> > >> list on the wiki
>>>>> > >>
>>>>> > >> On 7/15/13 11:30 AM, "Simon MacDonald"
>>>>><simon.macdonald@gmail.com>
>>>>> > wrote:
>>>>> > >>
>>>>> > >> >The reason things broke back then was we didn't leave
in shims
>>>>>to
>>>>> point
>>>>> > >> >anyone compiling against com.phonegap.api to
>>>>>org.apache.cordova.api.
>>>>> > That
>>>>> > >> >was quickly corrected.
>>>>> > >> >
>>>>> > >> >I agree with the package name change but with 3.0 shipping
this
>>>>> > week(?).
>>>>> > >> >It
>>>>> > >> >should probably wait until the next version.
>>>>> > >> >
>>>>> > >> >
>>>>> > >> >Simon Mac Donald
>>>>> > >> >http://hi.im/simonmacdonald
>>>>> > >> >
>>>>> > >> >
>>>>> > >> >On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux <b@brian.io>
>>>>>wrote:
>>>>> > >> >
>>>>> > >> >> No. You are proposing an API change. A package
is most
>>>>>certainly a
>>>>> > >> >> part of the API! When we moved from `com.phonegap`
to
>>>>>`org.apache`
>>>>> > >> >> there was a huge outcry b/c it broke all existing
community
>>>>> plugins.
>>>>> > >> >>
>>>>> > >> >> I'm completely open to changing stuff for 3.0
but, again, what
>>>>> > >> >> specifically are you proposing we change?
>>>>> > >> >>
>>>>> > >> >>
>>>>> > >> >>
>>>>> > >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI
>>>>><anis.kadri@gmail.com
>>>>> >
>>>>> > >> >>wrote:
>>>>> > >> >> > I agree. The only downside I see is that
it will be hard to
>>>>> > dissociate
>>>>> > >> >> core
>>>>> > >> >> > plugins from other but I don't think it's
really that
>>>>>important.
>>>>> > Also
>>>>> > >> >> > because it's not a giant change it could
happen for 3.0.
>>>>> > >> >> >
>>>>> > >> >> >
>>>>> > >> >> > On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren
<
>>>>> maxw@chromium.org>
>>>>> > >> >> wrote:
>>>>> > >> >> >
>>>>> > >> >> >> I'm not proposing any API changes in
this email; example
>>>>>(1)
>>>>> does
>>>>> > >> >> mention
>>>>> > >> >> >> the relocation of FileHelper.java, but
that's more to
>>>>>illustrate
>>>>> > the
>>>>> > >> >> >> benefits of repackaging the plugins.
>>>>> > >> >> >>
>>>>> > >> >> >> I would think the plugin package change
should happen *for*
>>>>>3.0,
>>>>> > >> >>before
>>>>> > >> >> >> people actually start using the plugins
all bundled in one
>>>>> > package.
>>>>> > >> >>  It's
>>>>> > >> >> >> not a giant change.
>>>>> > >> >> >>
>>>>> > >> >> >> On Mon, Jul 15, 2013 at 1:16 PM, Brian
LeRoux <b@brian.io>
>>>>> wrote:
>>>>> > >> >> >>
>>>>> > >> >> >> > I think all of this makes good sense
but will have to
>>>>>land
>>>>> > sometime
>>>>> > >> >> >> > post 3.0 as that we're pretty much
in the final stretch
>>>>>now
>>>>> > anyhow.
>>>>> > >> >> >> > Which APIs are you specifically
proposing we change?
>>>>> > >> >> >> >
>>>>> > >> >> >> >
>>>>> > >> >> >> >
>>>>> > >> >> >> > On Mon, Jul 15, 2013 at 9:14 AM,
Max Woghiren <
>>>>> > maxw@chromium.org>
>>>>> > >> >> wrote:
>>>>> > >> >> >> > > On Android, all Cordova plugins
are in the package
>>>>> > >> >> >> > org.apache.cordova.core.
>>>>> > >> >> >> > >  It makes sense to put each
plugin into its own
>>>>>package.
>>>>> >  Aside
>>>>> > >> >>from
>>>>> > >> >> >> > 3.0's
>>>>> > >> >> >> > > conceptual shift into "plugins
as completely individual
>>>>> > entities"
>>>>> > >> >> and
>>>>> > >> >> >> the
>>>>> > >> >> >> > > fact that plugins aren't really
"core", here's some
>>>>> rationale:
>>>>> > >> >> >> > >
>>>>> > >> >> >> > >    1. If two plugins have a
file with the same name,
>>>>>we'll
>>>>> > avoid
>>>>> > >> >> >> > >    collisions.  For instance,
core Cordova has
>>>>> > FileHelper.java.
>>>>> > >> >>  This
>>>>> > >> >> >> is
>>>>> > >> >> >> > the
>>>>> > >> >> >> > >    wrong place for it in 3.0
and we'd like to move it
>>>>>to
>>>>>the
>>>>> > >> >>plugins
>>>>> > >> >> >> > that use
>>>>> > >> >> >> > >    it (removing unused methods
in each plugin's
>>>>>version).
>>>>> > >> >>However,
>>>>> > >> >> >> this
>>>>> > >> >> >> > will
>>>>> > >> >> >> > >    lead to a collision in apps
that use two of these
>>>>> plugins,
>>>>> > >> >>since
>>>>> > >> >> >> > they'll
>>>>> > >> >> >> > >    both be in the same package.
>>>>> > >> >> >> > >    2. All plugin files will
be separated into their
>>>>>packages
>>>>> > in
>>>>> > >> >>your
>>>>> > >> >> >> IDE.
>>>>> > >> >> >> > >     This makes working on an
individual plugin
>>>>>easier‹you
>>>>> can
>>>>> > see
>>>>> > >> >> the
>>>>> > >> >> >> > >    associated files at a glance.
 If I'm working on a
>>>>>plugin
>>>>> > with
>>>>> > >> >> >> > multiple
>>>>> > >> >> >> > >    files, I shouldn't have
to hunt for related files to
>>>>> ensure
>>>>> > >> >>I'm
>>>>> > >> >> not
>>>>> > >> >> >> > missing
>>>>> > >> >> >> > >    anything.
>>>>> > >> >> >> > >    3. Since our plugins will
be used as starting points
>>>>>for
>>>>> > >> >> third-party
>>>>> > >> >> >> > >    plugins, we won't accidentally
encourage plugin
>>>>> developers
>>>>> > to
>>>>> > >> >>use
>>>>> > >> >> >> the
>>>>> > >> >> >> > same
>>>>> > >> >> >> > >    namespace.
>>>>> > >> >> >> > >
>>>>> > >> >> >> > > I would propose something like
>>>>> > >> >> org.apache.cordova.plugin.<plugin_name>.
>>>>> > >> >> >> >
>>>>> > >> >> >>
>>>>> > >> >>
>>>>> > >>
>>>>> > >>
>>>>> >
>>>>>
>>>
>

Mime
View raw message