cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Plugin packages on Android
Date Tue, 16 Jul 2013 16:18:44 GMT
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