After an ‘npm install cordova’ all ‘npx cordova ..’ ARE calls to 
node_modules/cordova ...

> On May 27, 2019, at 5:01 PM, Dmitry Blotsky <dmitry.blot...@gmail.com> wrote:
> 
> Even if we agree to use NPX for the initial Cordova run, using it in every 
> call instead of "./node_modules/.bin/cordova" introduces major failure modes.
> 
> Dmitry
> 
>> On May 15, 2019, at 11:32 PM, Jesse <purplecabb...@gmail.com> wrote:
>> 
>> I think there is a disconnect on the actual proposal here.
>> 
>> Here's the pr again ( keep the discussion here please )
>> https://github.com/apache/cordova-docs/pull/987/files
>> 
>> The only real use of npx as a one-off command would be the call to create a
>> new app. ie. `npx cordova create dirname ...`
>> The instructions after that are to cd into the dir, and install cordova
>> locally.
>> All npx calls after that are run from inside a project folder and are just
>> the same as npm run commands, they access the binary exported in
>> node_modules/cordova
>> 
>> That said, I do still think npx should be presented as an alternative, and
>> not necessarily the 'preferred' way.
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, May 15, 2019 at 10:38 PM Dmitry Blotsky <dmitry.blot...@gmail.com>
>> wrote:
>> 
>>> In terms of exposure, btw, npx is indeed strictly worse than npm install.
>>> It checks for dependencies, installs them, and runs them: all at every call
>>> of a command. That is more frequent than how often anyone runs npm install,
>>> and is more overhead than running a shell command directly.
>>> 
>>> From a higher-up perspective though: every other software ecosystem gets
>>> by with just running commands in a shell. How is our situation so
>>> outlandish that the most time-tested tools don’t meet our command-running
>>> needs?
>>> 
>>> Dmitry
>>> 
>>>> On May 15, 2019, at 22:29, Dmitry Blotsky <dmitry.blot...@gmail.com>
>>> wrote:
>>>> 
>>>> If it’s any convincing data: none of React Native, Ionic, Angular,
>>> Ember, Meteor, or Vue mention npx.
>>>> 
>>>> They all recommend npm install -g or some variant using more mature
>>> tools.
>>>> 
>>>> I agree that it would be a piece of cake for us to instruct people to
>>> install cordova for the local user, or to use per-project installs of
>>> cordova. These options are all still pretty convenient, and don’t incur the
>>> security penalties of npx.
>>>> 
>>>> Dmitry
>>>> 
>>>>> On May 15, 2019, at 02:15, Jesse <purplecabb...@gmail.com> wrote:
>>>>> 
>>>>> Given how contentious this has become, I think our best approach would
>>> be
>>>>> to continue with our global install expectation, and add documentation
>>> on
>>>>> a) what to do if you have issues with `npm i -g cordova` [1]
>>>>> b) document how to do local dependencies and use npx ( this might be a
>>> good
>>>>> blog post as well as permanent documentation )
>>>>> 
>>>>> Regarding some of the issues stated previously:
>>>>> 
>>>>>>> Dmitry: 1. It is strictly less secure than the status quo, and all
>>>>> alternatives. ..
>>>>> The exposure to the user is no different than `npm install -g`, it is
>>> just
>>>>> harder to know exactly what is happening.
>>>>> 
>>>>>>> Dmitry: 2. It is strictly less stable than a local installation ...
>>>>> Only the first `npx cordova create ...` will result in a fetch, further
>>>>> uses of npx cordova will use the cached version, and can be done
>>> without a
>>>>> network connection.
>>>>> 
>>>>>>> Darryl: Encouraging people to install Cordova globally causes issues
>>>>> when working on multiple projects ...
>>>>> Do we have a way of knowing how often this occurs? It sounds rare to me.
>>>>> Regardless, there is no reason they can't go ahead install
>>> cordova@version
>>>>> as a dev dependency
>>>>> 
>>>>> Personally, having read up on npx and done some basic tests, I am okay
>>> with
>>>>> it.  However, I also don't feel we have to force it on everyone.
>>>>> We can suggest is as an alternative, and perhaps after we are all more
>>>>> comfortable with it, it can become the default.
>>>>> 
>>>>> 
>>>>> [1]
>>>>> 
>>> https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, May 14, 2019 at 8:12 PM gandhi rajan <gandhiraja...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi Dmitry,
>>>>>> 
>>>>>> I second you on this.
>>>>>> 
>>>>>>> On Tuesday, May 14, 2019, Dmitry Blotsky <dmitry.blot...@gmail.com>
>>> wrote:
>>>>>>> 
>>>>>>> I'm really glad this discussion lit up, because it clearly shows that
>>>>>> this
>>>>>>> issue isn't settled.
>>>>>>> 
>>>>>>> I personally have few opinions about the "best" solution here, but I
>>>>>>> firmly believe that npx is a non-starter for these 2 reasons:
>>>>>>> 1. It is strictly less secure than the status quo, and all
>>> alternatives.
>>>>>>> It is literally downloading code from hundreds of untrusted parties
>>> and
>>>>>>> immediately running it. It's worse than piping a curl command into
>>> bash
>>>>>> (at
>>>>>>> least you can check the curl command's URL, or checksum the downloaded
>>>>>>> script).
>>>>>>> 2. It is strictly less stable than a local installation because now
>>> every
>>>>>>> call to Cordova goes through an opaque dependency.
>>>>>>> 
>>>>>>> Unless both of those can be addressed, I think we shouldn't consider
>>> npx.
>>>>>>> 
>>>>>>> Dmitry
>>>>>>> 
>>>>>>>> On May 10, 2019, at 4:31 PM, Oliver Salzburg <
>>>>>> oliver.salzb...@gmail.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Our DX is not good and this proposal would have the potential to
>>> have a
>>>>>>>> positive impact on that. I'm sorry that you're not convinced yet.
>>>>>>>> 
>>>>>>>> Because I don't want to skip back and forth between GitHub and the
>>>>>>>> mailing list, I'll address your points here.
>>>>>>>> 
>>>>>>>> - When you start a new project, unless you create a new cordova
>>> project
>>>>>>>> every week, you'll download cordova. npx will only help you in
>>>>>>>> downloading the package and if you have downloaded it in the past, it
>>>>>>>> will be pulled from the cache.
>>>>>>>> 
>>>>>>>> - Yes, the Cordova CLI behavior can change over time, which is
>>> exactly
>>>>>>>> why you would not want to share a single global version with all of
>>>>>> your
>>>>>>>> projects. I consider this a pro-local point.
>>>>>>>> 
>>>>>>>> - It is 4 more characters to type. Yes. I give you that. But if you
>>>>>> want
>>>>>>>> to interact with a local installation of cordova, what exactly is the
>>>>>>>> alternative? Not installing locally? I disagree.
>>>>>>>> 
>>>>>>>> - Your suggestion regarding writing a completely new module to
>>> initiate
>>>>>>>> a cordova project is completely besides the point here. If you had
>>> that
>>>>>>>> module, you'd still want to use it with npx. And using `npx cordova`
>>>>>>>> pulls cordova into the cache where you are going to want to have it
>>>>>>>> anyway. If you had a slimmed down module, you now still need to
>>>>>> download
>>>>>>>> cordova.
>>>>>>>> 
>>>>>>>> By using npx, given your usage examples, you would have less
>>> downloads
>>>>>>>> instead of more.
>>>>>>>> 
>>>>>>>> I'm sorry, Brody, I don't see your points and I don't feel like they
>>>>>>>> have been weighed appropriately against the benefits I proposed
>>>>>> earlier.
>>>>>>>> 
>>>>>>>> I would also appreciate it if we could try to keep the conversation
>>> to
>>>>>> a
>>>>>>>> single media. The split between mailing list and GitHub is not
>>>>>>> constructive.
>>>>>>>> 
>>>>>>>> Almost like putting part of your application in a global context and
>>>>>>>> another part in a local context is not constructive...
>>>>>>>> 
>>>>>>>>> On 2019-05-10 23:08, Chris Brody wrote:
>>>>>>>>> I am very sorry to say that I am still not convinced about this
>>> idea.
>>>>>>>>> I just raised some concerns in a recent comment in:
>>>>>>>>> https://github.com/apache/cordova-docs/issues/838
>>>>>>>>> 
>>>>>>>>> And I think I am not the only one right now.
>>>>>>>>> 
>>>>>>>>> As I said in cordova-docs#838, I would favor that we mention using
>>>>>>>>> `npx cordova` *as an option* in a limited number of places.
>>>>>>>>> 
>>>>>>>>> I would like to express my appreciation to Oliver for the time and
>>>>>>>>> effort has given to improve the documentation, and to contribute a
>>>>>>>>> number of updates and fixes in the past. But I would rather take the
>>>>>>>>> extra time and effort to ensure we keep up the best app DX we can.
>>>>>>>>> 
>>>>>>>>> And I don't really follow what you mean about CORDOVA_CMDLINE, would
>>>>>>>>> probably be easiest if we keep it in a separate discussion thread or
>>>>>>>>> issue.
>>>>>>>>> 
>>>>>>>>> On Fri, May 10, 2019 at 3:05 PM Oliver Salzburg
>>>>>>>>> <oliver.salzb...@gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> I have already started working on a PR to make the necessary
>>> changes
>>>>>> to
>>>>>>>>>> the documentation, as I was under the impression that consensus
>>>>>>>>>> regarding this issue was already reached:
>>>>>>>>>> 
>>>>>>>>>> https://github.com/apache/cordova-docs/pull/987
>>>>>>>>>> 
>>>>>>>>>> Specifically this might be of interest:
>>>>>>>>>> 
>>>>>>>>>> https://github.com/apache/cordova-docs/blob/
>>>>>>> 04363c2796199f5379fa2b5f000099ac8b1a488a/www/docs/en/dev/
>>>>>>> guide/cli/index.md
>>>>>>>>>> 
>>>>>>>>>> I believe installing the cordova dependency as a devDependency
>>> should
>>>>>>> be
>>>>>>>>>> part of the "create" task. I was planning to propose the necessary
>>>>>>>>>> changes in another PR, but the freshly ignited debate caused me to
>>>>>> hold
>>>>>>>>>> on that.
>>>>>>>>>> 
>>>>>>>>>> I also brought up another area of concern regarding CORDOVA_CMDLINE
>>>>>> in
>>>>>>>>>> hooks. I mentioned this in the PR.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 2019-05-10 20:42, Jesse wrote:
>>>>>>>>>>> Also thanks for the comprehensive write-up Oliver!
>>>>>>>>>>> 
>>>>>>>>>>> Yeah, I am good with a move to recommend npx.
>>>>>>>>>>> I just ran thru the steps and everything seems to work fine with
>>> it.
>>>>>>>>>>> 
>>>>>>>>>>> One other reservation I had was just about network usage, and
>>> being
>>>>>>>>>>> sensitive to places where bandwidth during the day is extremely
>>>>>>> costly.  I
>>>>>>>>>>> verified that having previously installed platforms android+ios in
>>>>>>> other
>>>>>>>>>>> projects, I was able to `npx cordova platform add android` with
>>> the
>>>>>>> network
>>>>>>>>>>> off and it used a cached version.
>>>>>>>>>>> 
>>>>>>>>>>> Are our new getting started steps going to be this ?:
>>>>>>>>>>> ```
>>>>>>>>>>> npx cordova create myNewCordovaApp
>>>>>>>>>>> cd myNewCordovaApp
>>>>>>>>>>> npm i cordova --save-dev
>>>>>>>>>>> npx cordova platform add android
>>>>>>>>>>> npx cordova run android
>>>>>>>>>>> ```
>>>>>>>>>>> 
>>>>>>>>>>> I believe we may also find some issues around cordova-lib having
>>>>>>>>>>> expectations of number of args and how it outputs some error
>>>>>>> messages, but
>>>>>>>>>>> hopefully tests will reveal those.
>>>>>>>>>>> 
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Jesse
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, May 10, 2019 at 2:46 AM <raphine...@gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks for that structured write-up, Oliver. You saved me from
>>>>>>> writing all
>>>>>>>>>>>> of that myself.
>>>>>>>>>>>> 
>>>>>>>>>>>> +100 on all those points
>>>>>>>>>>>> 
>>>>>>>>>>>> Oliver Salzburg <oliver.salzb...@gmail.com> schrieb am Fr., 10.
>>>>>> Mai
>>>>>>> 2019,
>>>>>>>>>>>> 11:01:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I don't see how third-party tools like nvm or nvm-windows play a
>>>>>>> role in
>>>>>>>>>>>>> this. If those tools have defects, so be it, but that shouldn't
>>>>>>> steer a
>>>>>>>>>>>>> decision when the tools in question ship with the official tools
>>>>>>> that we
>>>>>>>>>>>>> use (NodeJS).
>>>>>>>>>>>>> This holds especially true if the issues have already been
>>> fixed.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That being said, it seems like part of this discussion is
>>> already
>>>>>>> going
>>>>>>>>>>>>> into a direction of local vs. global Cordova install, which I
>>>>>> didn't
>>>>>>>>>>>>> even think was up for debate anymore. What was up for debate
>>> last
>>>>>>> night,
>>>>>>>>>>>>> was how to interact with local Cordova installs.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> However, let me reiterate all points regarding the entire issue:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 1. A global Cordova installation is a huge issue in itself, as
>>>>>>>>>>>>> components in Cordova interact with each other in a way that
>>>>>>> sometimes
>>>>>>>>>>>>> the global components are used and sometimes the local
>>> components.
>>>>>>> This
>>>>>>>>>>>>> happens during runs of individual tasks, like "prepare", where
>>>>>> both
>>>>>>> the
>>>>>>>>>>>>> local and the global cordova-common are loaded for example.
>>>>>>>>>>>>> This issue would easily be avoided by placing Cordova itself
>>>>>>> locally in
>>>>>>>>>>>>> the project. It allows a per-project Cordova version, which is
>>>>>>>>>>>>> controlled through the package.json, like any other Cordova
>>>>>>> component.
>>>>>>>>>>>>> Having your core component global is a horrible design and many
>>>>>>> other
>>>>>>>>>>>>> projects have already realized this years ago and adjusted
>>>>>>> accordingly.
>>>>>>>>>>>>> Think gulp-cli, babel-cli, ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The current approach leads to extremely hard to debug issues
>>> and,
>>>>>>>>>>>>> ultimately, developer frustration.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2. Interacting with a local dependency that has a binary
>>>>>> entrypoint
>>>>>>> in
>>>>>>>>>>>>> node_modules/.bin is exactly what npx was made for. It is
>>> already
>>>>>>>>>>>>> established as a tool in the NodeJS world and many other
>>> projects
>>>>>>> make
>>>>>>>>>>>>> use of it in the manner we're suggesting.
>>>>>>>>>>>>> https://reactjs.org/docs/create-a-new-react-app.html
>>>>>>>>>>>>> https://babeljs.io/docs/en/babel-cli
>>>>>>>>>>>>> https://gulpjs.com/docs/en/getting-started/quick-start
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There needs to be a very good reason to avoid adapting a well
>>>>>>>>>>>>> established approach in the environment you're working in. I'll
>>>>>> get
>>>>>>> to
>>>>>>>>>>>>> that.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 3. Suggesting npx as a way to interact with the Cordova CLI not
>>>>>> only
>>>>>>>>>>>>> serves the purpose of invoking the node_module/.bin entrypoint,
>>>>>> but
>>>>>>> it
>>>>>>>>>>>>> will also already work to create a new project when cordova
>>> isn't
>>>>>>> even
>>>>>>>>>>>>> installed. This reduces the barrier of entry and establishes a
>>> way
>>>>>>> to
>>>>>>>>>>>>> interact with Cordova that will always work.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> It is extremely convenient and developers want convenience. If
>>>>>>> there is
>>>>>>>>>>>>> one thing we don't need in Cordova, then it is to overcomplicate
>>>>>>> things,
>>>>>>>>>>>>> frustrate developers and drive them away.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 4. That being said, convenience comes at a price and Dmitry has
>>>>>>> outlined
>>>>>>>>>>>>> the issues that come with npx very well last night on Slack. I
>>>>>> agree
>>>>>>>>>>>>> with his points and they are also my own, but I feel the
>>> benefits
>>>>>>>>>>>>> massively outweigh these risks.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> npx downloads packages that aren't available locally and
>>> executes
>>>>>>> them.
>>>>>>>>>>>>> This is by-design and a feature I mentioned earlier. It also
>>> opens
>>>>>>> the
>>>>>>>>>>>>> door for a myriad of security issues, as it has the potential to
>>>>>> run
>>>>>>>>>>>>> unwanted code with every single execution of `npx cordova`.
>>>>>>>>>>>>> You just have to type `npx cordoa` once, and suddenly you get a
>>>>>>>>>>>>> typosquatted package from someone that sends off local data to
>>> the
>>>>>>>>>>>>> cloud. As a matter of fact, I published the package "rebecca"
>>>>>> years
>>>>>>> ago
>>>>>>>>>>>>> to illustrate exactly this point. Try `npx rebecca` to see what
>>> I
>>>>>>> mean.
>>>>>>>>>>>>> While you can run npx with --no-install to avoid this, this
>>> would
>>>>>>> ruin
>>>>>>>>>>>>> any convenience we're trying to establish here.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> npx also adds another layer of complexity. You need an
>>> additional
>>>>>>> Node
>>>>>>>>>>>>> process to even locate the entrypoint you want to invoke, check
>>> if
>>>>>>>>>>>>> downloads need to be made and so on. This would happen every
>>>>>> single
>>>>>>> time
>>>>>>>>>>>>> you invoke the Cordova CLI. I consider this a minor issue, but
>>> it
>>>>>>> is an
>>>>>>>>>>>>> issue nonetheless.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> With those points in mind, nobody is forced to use Cordova in
>>> the
>>>>>>> way we
>>>>>>>>>>>>> suggest in the docs. I can already install Cordova locally and
>>> use
>>>>>>> it
>>>>>>>>>>>>> with npx if I want to. Users who prefer a global installation of
>>>>>>> Cordova
>>>>>>>>>>>>> to avoid the above mentioned issues, are still free to do so and
>>>>>>> they
>>>>>>>>>>>>> should find instructions on how to set that up in the
>>>>>> documentation.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This is about suggesting to users a way to get started with
>>>>>> Cordova
>>>>>>> with
>>>>>>>>>>>>> as little friction as possible and npx achieves this extremely
>>>>>> well
>>>>>>> and
>>>>>>>>>>>>> leaves us with a far better project structure by default.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 10/05/2019 10:06, Jan Piotrowski wrote:
>>>>>>>>>>>>>> While that is correct, nvm-windows indeed had problems with npx
>>>>>> not
>>>>>>>>>>>>>> working after it was first added to node - so Julio's was
>>> indeed
>>>>>>> true
>>>>>>>>>>>>>> in the past.
>>>>>>>>>>>>>> Luckily it was fixed, so even we lowly Windows users now can
>>> use
>>>>>>> npx.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Am Fr., 10. Mai 2019 um 09:48 Uhr schrieb Oliver Salzburg
>>>>>>>>>>>>>> <oliver.salzb...@gmail.com>:
>>>>>>>>>>>>>>> npx ships with Node.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Fri, May 10, 2019, 00:33 Jesse <purplecabb...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hello Dmitry,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> In my mind, cordova-cli is intended to be installed globally,
>>>>>> in
>>>>>>>>>>>>> situations
>>>>>>>>>>>>>>>> where that is not is possible we could *maybe* recommend that
>>>>>>> users
>>>>>>>>>>>> use
>>>>>>>>>>>>>>>> npx, but I don't think it's a great experience.  btw, npx
>>> needs
>>>>>>> to be
>>>>>>>>>>>>>>>> globally installed ... so ok!?
>>>>>>>>>>>>>>>> This is really just a symptom of a bad node setup, and would
>>>>>>> never
>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>> if using nvm or similar node switcher.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> The issue raised in that thread appears to be simply related
>>> to
>>>>>>> where
>>>>>>>>>>>>>>>> config stores its data, specifically opt in/out of telemetry.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Thu, May 9, 2019 at 2:45 PM Dmitry Blotsky <
>>>>>>>>>>>>> dmitry.blot...@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> It’s been a while. :) I hope you’re all doing well.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I’m writing to start some mailing list discussion about this
>>>>>>> GitHub
>>>>>>>>>>>>>>>> issue:
>>>>>>>>>>>>>>>>> https://github.com/apache/cordova-docs/issues/838.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Please say if we should continue talking there, and we can
>>> do
>>>>>>> that
>>>>>>>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>> If not, let’s continue here.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> It sounds like we’ve got a request to run Cordova without a
>>>>>>> global
>>>>>>>>>>>>> sudo
>>>>>>>>>>>>>>>>> install. What are the ways you all can think of to achieve
>>>>>> this?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Regards,
>>>>>> Gandhi
>>>>>> 
>>>>>> "The best way to find urself is to lose urself in the service of others
>>>>>> !!!"
>>>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>> 
>>> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Reply via email to