cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikhil Khandelwal <nikhi...@microsoft.com>
Subject RE: [Discuss] Cordova-common release
Date Wed, 21 Oct 2015 16:31:26 GMT
It should not - it's a good change for Android 5.0. However, it does represent a big change
and we need more testing. From what I understand, it's release ready with no known issues.
Vladimir: Is that correct?

As for the cordova-common dependency, cordova-android will bundle it. And we don't have to
wait for a cordova-common release to release cordova-android.

-Nikhil

-----Original Message-----
From: Joe Bowser [mailto:bowserj@gmail.com] 
Sent: Wednesday, October 21, 2015 9:19 AM
To: dev <dev@cordova.apache.org>
Subject: Re: [Discuss] Cordova-common release

OK, how will this impact the 5.0 release of Android?

On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal <nikhilkh@microsoft.com>
wrote:

> It got checked in earlier this morning.
>
> -Nikhil
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, October 20, 2015 2:34 PM
> To: dev <dev@cordova.apache.org>
> Subject: Re: [Discuss] Cordova-common release
>
> So, when did the PlatformAPI change land in Android?
>
> On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N <panarasi@microsoft.com>
> wrote:
>
> > +1 - YES please. Requiring cordoba-common for my
> > react-native-cordova-plugin adapter was a nightmare !!
> >
> >
> >
> >
> > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" <nikhilkh@microsoft.com>
> wrote:
> >
> > >+1 to publishing cordova-common to npm.
> > >
> > >-Nikhil
> > >
> > >-----Original Message-----
> > >From: Steven Gill [mailto:stevengill97@gmail.com]
> > >Sent: Tuesday, October 20, 2015 2:20 PM
> > >To: dev@cordova.apache.org
> > >Subject: Re: [Discuss] Cordova-common release
> > >
> > >I want to revisit this.
> > >
> > >So cordova-android has a dependency now on cordova-common. It is a
> > bundledDependency so when we generate a tar to release 
> > cordova-android, it will be included. It will also be in the 
> > cordova-android package that gets downloaded with cordova platform add.
> > >
> > >This is fine for released work, but more annoying for development. 
> > >I need
> > to npm link cordova-common into cordova-android (and soon every 
> > platform which implements common platformAPI). We could check in 
> > cordova-common into cordova-android but that isn't a great solution
> either.
> > >
> > >I agree that we should be going towards smaller modules and not 
> > >having a
> > case of cordovaLib1, cordovaLib2, etc. I think this is still going 
> > to be a work in progress and will take some time.
> > >
> > >For the interim, I recommend we publish cordova-common. Of course,
> > continue to add it as a bundledDependency so users don't need to npm 
> > install it with released packages.
> > >
> > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) <
> > v-vlkoti@microsoft.com> wrote:
> > >
> > >> > I still do not understand what are you trying to solve by 
> > >> > having all
> > >> that content published as big blob.
> > >> Code deduplication is the main reason. All the things from 
> > >> 'cordova-common' will be used by platforms intensively, so we 
> > >> need to share this code and keep it separately from LIB to share easily.
> > >> Publishing is basically doesn't required for this, and bundling 
> > >> 'cordova-common' into LIB is enough for this purpose.
> > >>
> > >> Another reason was that third-party tool might want to use some 
> > >> of this functionality (like your example with ConfigParser), so 
> > >> we need to have this package on NPM to allow them to get it. For 
> > >> this case I now do agree with you that separate packages for 
> > >> ConfigParser, PluginInfo and other stuff looks better than 
> > >> putting it into one big
> > package.
> > >>
> > >> -
> > >> Best regards, Vladimir
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Carlos Santana [mailto:csantana23@gmail.com]
> > >> Sent: Wednesday, September 30, 2015 2:07 PM
> > >> To: dev@cordova.apache.org
> > >> Subject: Re: [Discuss] Cordova-common release
> > >>
> > >> Yes temporary, maybe we can discuss some more in F2F
> > >>
> > >> I still do not understand what are you trying to solve by having 
> > >> all that content published as big blob.
> > >>
> > >> If the packages are only for Cordova components to depend on then 
> > >> we control the release and we can include them easily.
> > >>
> > >> If the code is to be share by third party or anyone out there 
> > >> then it make sense to put in npm.
> > >>
> > >> One concrete example is cordova-configparser, Our IBM tool is 
> > >> using it in our own models code so today we taking a copy, if 
> > >> it's available thru npm then we can stated as a dependency and 
> > >> manage it as a npm package vs a loosely node module js file
> > >>
> > >> Maybe not all classes need to be converted to npm packages maybe 
> > >> it can be some cordova-configparser cordova-utils cordova-helper
> > >>
> > >> Also do some refactoring and dependency cleaning, I saw a node 
> > >> module dependeding on underscore and the file only had one simple 
> > >> call to
> > >> _.find()
> > >>
> > >> We were going to use that module, but then decided not to since 
> > >> it depended on underscore for a simple thing, this creates legal 
> > >> clearance work and more dependencies we need to include in our 
> > >> product making our download larger.
> > >>
> > >> And yes, yes we bundle all our dependencies when we go into
> production.
> > >>
> > >> - Carlos
> > >> Sent from my iPhone
> > >>
> > >> > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) <
> > >> v-vlkoti@microsoft.com> wrote:
> > >> >
> > >> > Including cordova-common as bundled dependency should be enough 
> > >> > in our
> > >> case. Changes to coho are submitted already [1], so we only need 
> > >> to update package.json for cordova-lib.
> > >> >
> > >> > Personally  for me bundling looks like a temporary workaround 
> > >> > before we
> > >> get all those partials of 'common' published to npm, am I right?
> > >> >
> > >> > [1]
> > >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
> > >> > 2f
> > >> > git
> > >> > hu
> > >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > >> > ti
> > >> > %40
> > >> > 06
> > >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > >> > 8b
> > >> > f86
> > >> > f1
> > >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > >> > fm
> > >> > %2b
> > >> > do
> > >> > 9WX4V4JfT0%3d
> > >> >
> > >> > -
> > >> > Best regards, Vladimir.
> > >> >
> > >> > -----Original Message-----
> > >> > From: Carlos Santana [mailto:csantana23@gmail.com]
> > >> > Sent: Tuesday, September 29, 2015 9:15 PM
> > >> > To: dev@cordova.apache.org
> > >> > Subject: Re: [Discuss] Cordova-common release
> > >> >
> > >> > Do we need to absolutely publish this to npm?
> > >> >
> > >> > Can we just include the dependency in the platform as a bundle
> > >> dependency?
> > >> >
> > >> > We just need to update coho to npm install/link the 
> > >> > cordoba-common package when doing a release of what ever 
> > >> > component
> need it? (i.e.
> > >> > cordova-android)
> > >> >
> > >> > Will this get you what you want? Why does it absolutely need to 
> > >> > be in
> > >> npm registry?
> > >> >
> > >> > I really don't think will be a good idea to publish two npm 
> > >> > packages
> > >> "cordova-lib" and "cordova-common"
> > >> >
> > >> > Sorry if I'm being a pain in the ass, maybe I'm something 
> > >> > obvious here
> > >> >
> > >> >
> > >> >> On Tue, Sep 29, 2015 at 1:34 PM Steven Gill 
> > >> >> <stevengill97@gmail.com>
> > >> wrote:
> > >> >>
> > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM, 
> > >> >> "Nikhil Khandelwal"
> > >> >> <nikhilkh@microsoft.com>
> > >> >> wrote:
> > >> >>
> > >> >>> +1. I understand the value of Carlos' proposal, but in the

> > >> >>> +spirit of
> > >> >>> moving forward with this which is fairly complicated refactor

> > >> >>> involving multiple releases and repos, I would like us to

> > >> >>> make progress on this
> > >> >> soon
> > >> >>> and not add significant scope to this effort.
> > >> >>>
> > >> >>>
> > >> >>> -Nikhil
> > >> >>>
> > >> >>> -----Original Message-----
> > >> >>> From: Sergey Grebnov (Akvelon) 
> > >> >>> [mailto:v-segreb@microsoft.com]
> > >> >>> Sent: Tuesday, September 29, 2015 1:34 AM
> > >> >>> To: dev@cordova.apache.org
> > >> >>> Subject: RE: [Discuss] Cordova-common release
> > >> >>>
> > >> >>> +1
> > >> >>>
> > >> >>> -----Original Message-----
> > >> >>> From: Vladimir Kotikov (Akvelon) 
> > >> >>> [mailto:v-vlkoti@microsoft.com]
> > >> >>> Sent: Tuesday, September 29, 2015 11:27 AM
> > >> >>> To: dev@cordova.apache.org
> > >> >>> Subject: RE: [Discuss] Cordova-common release
> > >> >>>
> > >> >>> Agree with you, guys.
> > >> >>>
> > >> >>> Unfortunately, the underlying modules in `cordova-common`
are 
> > >> >>> not really atomic, since they depending on each other. For

> > >> >>> example ConfigParser requires `xmlHelpers`, `events` and 
> > >> >>> `CordovaError` as a
> > >> dependencies.
> > >> >>> Reworking them to be truly separated might be sort of 
> > >> >>> problematic, especially in context of message logging (as

> > >> >>> they use shared event
> > >> >> emitter
> > >> >>> to log output to console).
> > >> >>>
> > >> >>> So I still propose is to release `common` module as-is and

> > >> >>> then gradually move inner modules out to separate packages.
> > >> >>>
> > >> >>> -
> > >> >>> Best regards, Vladimir.
> > >> >>>
> > >> >>> -----Original Message-----
> > >> >>> From: Carlos Santana [mailto:csantana23@gmail.com]
> > >> >>> Sent: Friday, September 25, 2015 7:33 PM
> > >> >>> To: dev@cordova.apache.org
> > >> >>> Subject: Re: [Discuss] Cordova-common release
> > >> >>>
> > >> >>> Sorry a typo
> > >> >>> to use "bundleDependencies" you will have a node_modules/

> > >> >>> directory directly under "common/node_modules/cordova-error/"
> > >> >>>
> > >> >>> and the the small modules (i.e. cordoba-util, 
> > >> >>> cordova-plugin-info,
> > >> >>> etc..) will be located there.
> > >> >>>
> > >> >>> then have explicit ignores for the dependencies you don't

> > >> >>> want to be source control like npm [2]
> > >> >>>
> > >> >>> [2]:
> > >> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f
> > >> >> %2
> > >> >> fgi
> > >> >> th
> > >> >> u
> > >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > >> >> c0
> > >> >> 1%7
> > >> >> cv
> > >> >> -
> > >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> > >> >> 0e
> > >> >> 0f%
> > >> >> 7c
> > >> >> 7
> > >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > >> >> UP
> > >> >> 7AY
> > >> >> 4q
> > >> >> E
> > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > >> >>>
> > >> >>>
> > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana 
> > >> >>> <csantana23@gmail.com>
> > >> >>> wrote:
> > >> >>>
> > >> >>>> Yes after reviewing the changes, I understood the purpose
of 
> > >> >>>> the code that you seperated to avoid duplicate code between

> > >> >>>> the other top level modules (i.e. platforms, lib, cli)
> > >> >>>>
> > >> >>>> I still think small modules is the way to go.
> > >> >>>>
> > >> >>>> Don't let process, bureaucracy, and ceremony hamper the

> > >> >>>> engineering process and the consumer UX using this modules.
> > >> >>>> (yeah that came out from the mouth of an IBMer ;-p)
> > >> >>>>
> > >> >>>> Yes, I'm not blind, I understand the voting, the releasing,

> > >> >>>> the packaging the publish steps
> > >> >>>>
> > >> >>>> The way I look at it no matter what you do you are not
going 
> > >> >>>> to make it easier by having one "common" package.
> > >> >>>>
> > >> >>>> Let's say you just need to update a file to fix a bug
from 
> > >> >>>> Error, well you need to test, vote, release, "common"
> > >> >>>> Next you want to fix a bug in configparser, guess what
you 
> > >> >>>> need to tests, vote, release "common" again But if only

> > >> >>>> config parser changed all the rest of the code in "common"
> > >> >>>> needs to be tested and release, and consumer will need
to 
> > >> >>>> pick a new common for only a small bug fix in a portion
of "common"
> > >> >>>>
> > >> >>>> Basically that's what we have today, the way I see it
you 
> > >> >>>> are just creating two libs "lib" and "lib2"
> > >> >>>>
> > >> >>>> With large number of small modules, lets say we create
8 
> > >> >>>> now, maybe only 2 change most of the time, and the other
5 
> > >> >>>> are so basic and small that they never change and stay
at 
> > >> >>>> version
> > >> >>>> 1.0.0
> > for  long time.
> > >> >>>>
> > >> >>>> I think for this small modules, I don't think we have
to do 
> > >> >>>> the blog post, twitter things, those I will continue to
have 
> > >> >>>> for the large components (cli, platforms, plugins)
> > >> >>>>
> > >> >>>> Also the side effect I would like to see, is clean APIs

> > >> >>>> edges, each small module provides an API, it contain tests

> > >> >>>> to that API, and lib contain integration tests as a whole.
> > >> >>>>
> > >> >>>> Maybe the compromise for now, to move forward let's break

> > >> >>>> the functions into "npm packages" inside this "common"
where 
> > >> >>>> each sub directory inside common is a npm package with
a 
> > >> >>>> single entry point
> > >> >>>> (index.js) and common package.json have them as 
> > >> >>>> "bundleDependencies", similar way as npm does [1]
> > >> >>>>
> > >> >>>> the transition will be for consumers for their dependencies

> > >> >>>> and the way they consume the API
> > >> >>>> dependencies: {
> > >> >>>>   cordova-common: "1.0.0"
> > >> >>>> }
> > >> >>>> cordova-common only expose one index.js with the APIs
to the 
> > >> >>>> other modules
> > >> >>>>
> > >> >>>> var cdvUtil              = require("cordova-common").cordova-util
> > >> >>>> cdvPluginInfo          =
> > >> require("cordova-common").cordova-plugin-info,
> > >> >>>> cdvError                  =
> > require("cordova-common").cordova-error,
> > >> >>>> cdvConfigParser     =
> > require("cordova-common").cordova-config-parser,
> > >> >>>> cdvConfigChanges =
> > >> >>>> require("cordova-common").rcordova-config-changes);
> > >> >>>>
> > >> >>>> then it can be easier transition if we want to change
later, 
> > >> >>>> nothing much on our part since we already have the npm

> > >> >>>> packages implemented it's a matter if we want to make
them 
> > >> >>>> available on npm or
> > >> not.
> > >> >>>>
> > >> >>>> [1]:
> > >> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%
> > >> >>>> 2f
> > >> >>>> %2f
> > >> >>>> g
> > >> >>>> ithu
> > >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > >> >>>> =0
> > >> >>>> 1%7
> > >> >>>> c
> > >> >>>> 01%7
> > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d
> > >> >>>> 2c
> > >> >>>> 5c7
> > >> >>>> 0
> > >> >>>> e0f%
> > >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > >> >>>> bm
> > >> >>>> Vx5
> > >> >>>> 0
> > >> >>>> QKD2
> > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon)
< 
> > >> >>>> v-segreb@microsoft.com> wrote:
> > >> >>>>
> > >> >>>>> I tend to agree w/ Carlos here, but from practical
side it 
> > >> >>>>> might be very hard to maintain and release such a
granular 
> > >> >>>>> modules, for example,
> > >> >>>>> -  cordova-error has been updated ->Vote ->
update 
> > >> >>>>> cordova-config-parser
> > >> >>>>> + Vote-> update + Vote other depended modules
> > >> >>>>> - now we want to add some new feature: modules are
very 
> > >> >>>>> granular so we should introduce a new module
> > >> >>>>>
> > >> >>>>> But I totally love and support Carlos idea regarding

> > >> >>>>> grouping meaningful/independent logic in modules,
this is 
> > >> >>>>> how software must be designed.
> > >> >>>>>
> > >> >>>>> I personally think about this new module as some sort
of 
> > >> >>>>> core Cordova functionality and high level classes
which 
> > >> >>>>> could be used by cordova-lib/cli and platforms -unified

> > >> >>>>> CordovaError, events (output tracing, etc), working
with 
> > >> >>>>> config file, superspawn, etc
> > >> >>>>>
> > >> >>>>> Thx!
> > >> >>>>> Sergey
> > >> >>>>> -----Original Message-----
> > >> >>>>> From: Carlos Santana [mailto:csantana23@gmail.com]
> > >> >>>>> Sent: Thursday, September 24, 2015 6:31 PM
> > >> >>>>> To: dev@cordova.apache.org
> > >> >>>>> Subject: Re: [Discuss] Cordova-common release
> > >> >>>>>
> > >> >>>>> Sorry if I take my inner purist theoretical developer
out 
> > >> >>>>> for a minute :-)
> > >> >>>>>
> > >> >>>>> The point of having a "node module" it should be explicit

> > >> >>>>> and small, meaning that should be easy to name in
a way 
> > >> >>>>> that describes what it is or do.
> > >> >>>>>
> > >> >>>>> Take into account that "node module" is not the same
as a 
> > >> >>>>> "npm
> > >> >> package"
> > >> >>>>>
> > >> >>>>> Having 2 npm packages on the npm registry "cordova-common"
> > >> >>>>> and "cordova-lib" to the simple eye would look like

> > >> >>>>> duplicate packages, and then will need to answer multiple

> > >> >>>>> times "What is the difference between lib and common?"
> > >> >>>>>
> > >> >>>>> Why not have more smaller explicit npm packages instead?
> > >> >>>>>
> > >> >>>>> cordova-util
> > >> >>>>> cordova-plugin-info
> > >> >>>>> cordova-error
> > >> >>>>> cordova-config-parser
> > >> >>>>> cordova-config-changes
> > >> >>>>>
> > >> >>>>> each one with a index.js exposing APIs
> > >> >>>>>
> > >> >>>>> Then the programing model becomes something like this:
> > >> >>>>> var cdvUtil              = require('cordova-util'),
> > >> >>>>> cdvPluginInfo          = require('cordova-plugin-info'),
> > >> >>>>> cdvError                  = require('cordova-error'),
> > >> >>>>> cdvConfigParser     = require('cordova-config-parser'),
> > >> >>>>> cdvConfigChanges = require('cordova-config-changes');
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> On Thu, Sep 24, 2015 at 12:29 PM Sergey Grebnov (Akvelon)
< 
> > >> >>>>> v-segreb@microsoft.com> wrote:
> > >> >>>>>
> > >> >>>>>> Hi guys - we've decided to combine shared logic
as 
> > >> >>>>>> cordova-common module and publish it separately
(read [1] 
> > >> >>>>>> for
> > more details).
> > >> >>>>>> Corresponding change has landed to master[2] on
last week 
> > >> >>>>>> so I'm wondering if we should release this module
and then 
> > >> >>>>>> update LIB to rely
> > >> >>>>> on it (similar to cordova-serve).
> > >> >>>>>> So guys it will be great if we can review it one
more time 
> > >> >>>>>> (including the name - do we all  agree to use
> > >> >>>>>> cordova-common??) and then do release - I'll be
able to 
> > >> >>>>>> help w/ merging the recent changes added to LIB
before 
> > >> >>>>>> doing
> release.
> > >> >>>>>>
> > >> >>>>>> [1]
> > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fis
> > >> >>>>>> sue
> > >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > >> >>>>>> gr
> > >> >>>>>> eb%
> > >> >>>>>> 40mi
> > >> >>>>>> cro
> > >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > >> >>>>>> 41
> > >> >>>>>> af9
> > >> >>>>>> 1ab2
> > >> >>>>>> d7c
> > >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > >> >>>>>> rT
> > >> >>>>>> jwX
> > >> >>>>>> TXk%
> > >> >>>>>> 3d
> > >> >>>>>> [2]
> > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fgi
> > >> >>>>>> thu
> > >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > >> >>>>>> mo
> > >> >>>>>> n&d
> > >> >>>>>> ata=
> > >> >>>>>> 01%
> > >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2
> > >> >>>>>> c5
> > >> >>>>>> 491
> > >> >>>>>> 5f3%
> > >> >>>>>> 7c7
> > >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > >> >>>>>> I9
> > >> >>>>>> ASf
> > >> >>>>>> QMku
> > >> >>>>>> RV0
> > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > >> >>>>>>
> > >> >>>>>> Thx!
> > >> >>>>>> Sergey
> > >> >>>>>>
> > >> >>>>>> ----------------------------------------------------------
> > >> >>>>>> --
> > >> >>>>>> ---
> > >> >>>>>> ----
> > >> >>>>>> -- To unsubscribe, e-mail:
> > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > >> >>>>>> For additional commands, e-mail: 
> > >> >>>>>> dev-help@cordova.apache.org
> > >> >>>
> > >> >>> -------------------------------------------------------------
> > >> >>> --
> > >> >>> ---
> > >> >>> --
> > >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> > ---------------------------------------------------------------
> > >> > --
> > >> > ---
> > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > >?B 
> > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > >KKCB ? ?[  X  ܚX K??K[XZ[? ??] ][  X  ܚX P? ܙ?ݘK \?X ?K ܙ B  
> > >܈?Y??]?[ ۘ[??  [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
Mime
View raw message