Re: Auto-suffixing debug app id on Android

[Brian LeRoux]

So two apps, same name on the springboard/deck, but diff id?

On Tue, Jan 6, 2015, 7:46 PM Tommy Williams  wrote:

> As handy as having release and debug on the same device might be, this
> might be a job for a hook and a blog post about it, instead of a built in
> feature.
> On 07/01/2015 1:29 pm, "Andrew Grieve"  wrote:
>
> > Nope no JIRA, just something I stumbled across when I was reading gradle
> > docs and thought I'd bring up. One other thing it avoids is getting the
> > certificate mismatch failure when you switch between release and debug.
> > Good point about being confused as to which icon is which though.
> >
> > On Tue, Jan 6, 2015 at 7:55 PM, Joe Bowser  wrote:
> >
> > > I don't think this idea is entirely thought out.  I've had debug and
> > > release code on devices, and all it does is confuse me when I need to
> do
> > a
> > > demo of something.  Is there a JIRA issue regarding this new feature,
> > since
> > > I think this needs to be fleshed out more.
> > >
> > > On Tue Jan 06 2015 at 10:42:51 AM Andrew Grieve 
> > > wrote:
> > >
> > > > Mainly - it allows it to be installed alongside the release version
> of
> > > the
> > > > app.
> > > >
> > > > On Tue, Jan 6, 2015 at 11:01 AM, Brian LeRoux  wrote:
> > > >
> > > > > Why is it a good idea?
> > > > >
> > > > > On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve 
> > wrote:
> > > > >
> > > > > > With gradle, this is easy to do:
> > > > > >
> > > > > > android {
> > > > > > buildTypes {
> > > > > > debug {
> > > > > > applicationIdSuffix ".debug"
> > > > > > }
> > > > > >
> > > > > > Seems like a good idea to me, but I'm wondering if there may be
> > > reason
> > > > > not
> > > > > > to?
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Automated Unit-Testing for my plugin?

[Steven Gill]

I think that is a great idea!
On Jan 5, 2015 7:24 PM, "Parashuram N (MS OPEN TECH)" <
panar...@microsoft.com> wrote:

> It would be awesome if we could get medic to run plugins tests on custom
> plugins also, and if plugin developers could use this. What do you guys
> think?
>
> On 12/31/14, 5:07 AM, "Michael Bishop"  wrote:
>
> >Thank you very much!
> >
> >_ michael
> >
> >
> >On Tue, Dec 30, 2014 at 4:35 PM, Sergey Grebnov (Akvelon) <
> >v-seg...@microsoft.com> wrote:
> >
> >> Michael, take a look on the cordova-mobile-spec[1] which utilizes
> >> 'cordova-plugin-test-framework', there is special setting[2] here to
> >> specify what plugins to test.
> >> * You can use your custom Jasmine reporter which will trace tests
> >>results
> >> to the console (see example [4])
> >>
> >> I also recommend to take a look on Apache Cordova Medic[3] which is an
> >> automated test system built on top of cordova-mobile-spec; PS. we are
> >> working on some improvements to allow adding non-core plugins for
> >>testing
> >>
> >> [1]https://github.com/apache/cordova-mobile-spec
> >> [2]
> >>
> >>
> https://github.com/apache/cordova-mobile-spec/blob/master/dependencies-pl
> >>ugin/plugin.xml
> >> [3] https://github.com/apache/cordova-medic
> >> [4] http://jasmine.github.io/2.1/custom_reporter.html
> >>
> >> Thx!
> >> Sergey
> >> -Original Message-
> >> From: Michael Bishop [mailto:mbis...@fiksu.com]
> >> Sent: Tuesday, December 30, 2014 8:18 PM
> >> To: dev@cordova.apache.org
> >> Subject: Automated Unit-Testing for my plugin?
> >>
> >> Hello Cordova Folk!
> >>
> >> I have written small plugin for Cordova but want to automate my unit
> >>tests.
> >> I'm wondering what the endorsed solution is.
> >>
> >> Here's what I have:
> >>
> >> - Plugin
> >> - 'tests' directory (and associated plugin.xml file)
> >> - I've successfully used the 'cordova-plugin-test-framework' in a sample
> >> app where I've also included my plugin and the plugin's test plugin. The
> >> tests are running just fine.
> >>
> >> My question(s):
> >>
> >> How would I automate my test suite? Is it possible to run it via a
> >> command-line tool and retrieve the results?
> >>
> >> Many thanks as I know you are still developing this stuff!
> >>
> >> _ michael
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

RE: How to test the cordova-android 4.0 by mobile spec

[Fu, Junwei]

Yes, I set up mobilespec following  
https://github.com/apache/cordova-mobile-spec .

-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com] 
Sent: Wednesday, January 07, 2015 10:54 AM
To: dev@cordova.apache.org
Subject: Re: How to test the cordova-android 4.0 by mobile spec

So, it's not using the cordova that's installed locally via npm? I'll have to 
check that again.

On Tue Jan 06 2015 at 6:33:14 PM Andrew Grieve  wrote:

> I've just been checkout out 4.0.x branch of cordova-android, then 
> running the script. I think the script requires that 
> cordova-mobile-spec, cordova-android, and cordova-js all be sibling 
> directories.
>
> On Tue, Jan 6, 2015 at 7:58 PM, Joe Bowser  wrote:
>
> > I haven't been able to get mobile-spec working reliably since it was 
> > refactored and we were forced to use the createmobilespec.sh script (i.e.
> > Tests don't run on Android 2.3) How did you manage to get it to work 
> > with 4.0.x?
> >
> > On Tue Jan 06 2015 at 6:24:51 AM Andrew Grieve 
> > 
> > wrote:
> >
> > > I think you had it right. use cordova-mobile-spec@master and 
> > > cordova-android@4.0.x. Failing tests are likely issues (in android 
> > > or
> in
> > > the tests). Just fixed last night that the JS on 4.0.x was not 
> > > properly registering with the CoreAndroid plugin due to it being 
> > > renamed, so
> that
> > > could be the cause of the key event test failing.
> > >
> > > On Tue, Jan 6, 2015 at 3:47 AM, Fu, Junwei 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > Because There are no cordova-mobile-spec  4.0 branch, so I used 
> > > > cordova-mobile-spec master branch to test cordova-android 4.0, 
> > > > but
> the
> > > key
> > > > event test cases failed. And the splash screen test cases failed 
> > > > with cordova-mobile-spec 3.6 branch, I don't know how to test 
> > > > the cordova-android 4.0 by mobile spec.
> > > >
> > > > Thanks,
> > > > Junwei.
> > > >
> > >
> >
>

Re: How to test the cordova-android 4.0 by mobile spec

[Joe Bowser]

So, it's not using the cordova that's installed locally via npm? I'll have
to check that again.

On Tue Jan 06 2015 at 6:33:14 PM Andrew Grieve  wrote:

> I've just been checkout out 4.0.x branch of cordova-android, then running
> the script. I think the script requires that cordova-mobile-spec,
> cordova-android, and cordova-js all be sibling directories.
>
> On Tue, Jan 6, 2015 at 7:58 PM, Joe Bowser  wrote:
>
> > I haven't been able to get mobile-spec working reliably since it was
> > refactored and we were forced to use the createmobilespec.sh script (i.e.
> > Tests don't run on Android 2.3) How did you manage to get it to work with
> > 4.0.x?
> >
> > On Tue Jan 06 2015 at 6:24:51 AM Andrew Grieve 
> > wrote:
> >
> > > I think you had it right. use cordova-mobile-spec@master and
> > > cordova-android@4.0.x. Failing tests are likely issues (in android or
> in
> > > the tests). Just fixed last night that the JS on 4.0.x was not properly
> > > registering with the CoreAndroid plugin due to it being renamed, so
> that
> > > could be the cause of the key event test failing.
> > >
> > > On Tue, Jan 6, 2015 at 3:47 AM, Fu, Junwei 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > Because There are no cordova-mobile-spec  4.0 branch, so I used
> > > > cordova-mobile-spec master branch to test cordova-android 4.0, but
> the
> > > key
> > > > event test cases failed. And the splash screen test cases failed with
> > > > cordova-mobile-spec 3.6 branch, I don't know how to test the
> > > > cordova-android 4.0 by mobile spec.
> > > >
> > > > Thanks,
> > > > Junwei.
> > > >
> > >
> >
>

RE: How to test the cordova-android 4.0 by mobile spec

[Fu, Junwei]

I update the latest cordova-android 4.0.x, cordova-mobile-spec and cordova-js, 
the key event test cases still failed, and the cordova version is still MSTEST, 
not 4.0.

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Wednesday, January 07, 2015 10:30 AM
To: dev
Subject: Re: How to test the cordova-android 4.0 by mobile spec

I've just been checkout out 4.0.x branch of cordova-android, then running the 
script. I think the script requires that cordova-mobile-spec, cordova-android, 
and cordova-js all be sibling directories.

On Tue, Jan 6, 2015 at 7:58 PM, Joe Bowser  wrote:

> I haven't been able to get mobile-spec working reliably since it was 
> refactored and we were forced to use the createmobilespec.sh script (i.e.
> Tests don't run on Android 2.3) How did you manage to get it to work 
> with 4.0.x?
>
> On Tue Jan 06 2015 at 6:24:51 AM Andrew Grieve 
> wrote:
>
> > I think you had it right. use cordova-mobile-spec@master and 
> > cordova-android@4.0.x. Failing tests are likely issues (in android 
> > or in the tests). Just fixed last night that the JS on 4.0.x was not 
> > properly registering with the CoreAndroid plugin due to it being 
> > renamed, so that could be the cause of the key event test failing.
> >
> > On Tue, Jan 6, 2015 at 3:47 AM, Fu, Junwei  wrote:
> >
> > > Hi,
> > >
> > > Because There are no cordova-mobile-spec  4.0 branch, so I used 
> > > cordova-mobile-spec master branch to test cordova-android 4.0, but 
> > > the
> > key
> > > event test cases failed. And the splash screen test cases failed 
> > > with cordova-mobile-spec 3.6 branch, I don't know how to test the 
> > > cordova-android 4.0 by mobile spec.
> > >
> > > Thanks,
> > > Junwei.
> > >
> >
>

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

Re: Cordova-lib failing on master (stopping release)

[Andrew Grieve]

Gar, thanks for reverting and moving on. Sorry for not running tests :(

On Tue, Jan 6, 2015 at 5:54 PM, Steven Gill  wrote:

> Yup. I reverted to that commit. Pushed to master. Continuing with release.
>
> On Tue, Jan 6, 2015 at 2:46 PM, Mark Koudritsky  wrote:
>
> > This commit
> >
> >
> https://github.com/apache/cordova-lib/commit/b2e33f55e98f23116066f47f9b6ea5b49474d95c
> > passed on both AppVeyor
> > 
> and
> > Travis 
> >
>

Re: Auto-suffixing debug app id on Android

[Tommy Williams]

As handy as having release and debug on the same device might be, this
might be a job for a hook and a blog post about it, instead of a built in
feature.
On 07/01/2015 1:29 pm, "Andrew Grieve"  wrote:

> Nope no JIRA, just something I stumbled across when I was reading gradle
> docs and thought I'd bring up. One other thing it avoids is getting the
> certificate mismatch failure when you switch between release and debug.
> Good point about being confused as to which icon is which though.
>
> On Tue, Jan 6, 2015 at 7:55 PM, Joe Bowser  wrote:
>
> > I don't think this idea is entirely thought out.  I've had debug and
> > release code on devices, and all it does is confuse me when I need to do
> a
> > demo of something.  Is there a JIRA issue regarding this new feature,
> since
> > I think this needs to be fleshed out more.
> >
> > On Tue Jan 06 2015 at 10:42:51 AM Andrew Grieve 
> > wrote:
> >
> > > Mainly - it allows it to be installed alongside the release version of
> > the
> > > app.
> > >
> > > On Tue, Jan 6, 2015 at 11:01 AM, Brian LeRoux  wrote:
> > >
> > > > Why is it a good idea?
> > > >
> > > > On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve 
> wrote:
> > > >
> > > > > With gradle, this is easy to do:
> > > > >
> > > > > android {
> > > > > buildTypes {
> > > > > debug {
> > > > > applicationIdSuffix ".debug"
> > > > > }
> > > > >
> > > > > Seems like a good idea to me, but I'm wondering if there may be
> > reason
> > > > not
> > > > > to?
> > > > >
> > > >
> > >
> >
>

Re: Remove onDestroy event/channel from cordova-js

[Andrew Grieve]

The channel is defined here:
https://github.com/apache/cordova-js/blob/master/src/common/channel.js#L38
and clearly labeled as an internal event. I don't think it'd be considered
an API change to remove it.

On Tue, Jan 6, 2015 at 7:59 PM, Joe Bowser  wrote:

> Are we sure the feature never worked? I'm not wanting to kill a feature to
> find out that it worked on Android 2.x and that we broke someone's app.  I
> think more testing is needed before we decide to kill it.
>
> On Tue Jan 06 2015 at 4:57:25 PM Jesse  wrote:
>
> > Well, if we find that the feature never worked, then we could just remove
> > it.
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, Jan 6, 2015 at 4:52 PM, Joe Bowser  wrote:
> >
> > > This is an API change, and this would require a major version change
> for
> > > both Android and CordovaJS.
> > >
> > > On Tue Jan 06 2015 at 4:50:17 PM Shazron  wrote:
> > >
> > > > Fine with me (iOS has no use of it)
> > > >
> > > > On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase 
> > > wrote:
> > > > > I'm working on CB-8210, to remove the use of javascript eval()s
> from
> > > > native
> > > > > code in cordova-android.  The goal is to pave the way for CSP.
> > > > >
> > > > > One usage was to fire the "onDestroy" event when the app is being
> > > > > destroyed.  However, in my testing, I wasn't able to get this event
> > > > firing
> > > > > on the javascript side.  Upon investigation, I discovered that
> while
> > > the
> > > > > onDestroy is defined for all platforms (in channel.js), it is only
> > > > > implemented for android.  Further, the code defines it as an
> internal
> > > > > event, which should not be used in app code (guidance is to use
> > > > > window.onunload instead).  I couldn't find any internal code using
> > > > > onDestroy.
> > > > >
> > > > > Given the above, is there any reason to keep the onDestroy event?
> It
> > > > seems
> > > > > the simplest thing to do is remove the event, rather than spending
> > more
> > > > > effort on getting it to work under CSP.  As well, it's defined as
> an
> > > > > internal event, so I assume that removal would not be considered an
> > API
> > > > > change.
> > > > >
> > > > > I'd welcome any comments for/against removing onDestroy.
> > > > >
> > > > > Thanks,
> > > > > Jason
> > > > > Google Cordova team
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > > >
> > >
> >
>

Re: How to test the cordova-android 4.0 by mobile spec

[Andrew Grieve]

I've just been checkout out 4.0.x branch of cordova-android, then running
the script. I think the script requires that cordova-mobile-spec,
cordova-android, and cordova-js all be sibling directories.

On Tue, Jan 6, 2015 at 7:58 PM, Joe Bowser  wrote:

> I haven't been able to get mobile-spec working reliably since it was
> refactored and we were forced to use the createmobilespec.sh script (i.e.
> Tests don't run on Android 2.3) How did you manage to get it to work with
> 4.0.x?
>
> On Tue Jan 06 2015 at 6:24:51 AM Andrew Grieve 
> wrote:
>
> > I think you had it right. use cordova-mobile-spec@master and
> > cordova-android@4.0.x. Failing tests are likely issues (in android or in
> > the tests). Just fixed last night that the JS on 4.0.x was not properly
> > registering with the CoreAndroid plugin due to it being renamed, so that
> > could be the cause of the key event test failing.
> >
> > On Tue, Jan 6, 2015 at 3:47 AM, Fu, Junwei  wrote:
> >
> > > Hi,
> > >
> > > Because There are no cordova-mobile-spec  4.0 branch, so I used
> > > cordova-mobile-spec master branch to test cordova-android 4.0, but the
> > key
> > > event test cases failed. And the splash screen test cases failed with
> > > cordova-mobile-spec 3.6 branch, I don't know how to test the
> > > cordova-android 4.0 by mobile spec.
> > >
> > > Thanks,
> > > Junwei.
> > >
> >
>

Re: Auto-suffixing debug app id on Android

[Andrew Grieve]

Nope no JIRA, just something I stumbled across when I was reading gradle
docs and thought I'd bring up. One other thing it avoids is getting the
certificate mismatch failure when you switch between release and debug.
Good point about being confused as to which icon is which though.

On Tue, Jan 6, 2015 at 7:55 PM, Joe Bowser  wrote:

> I don't think this idea is entirely thought out.  I've had debug and
> release code on devices, and all it does is confuse me when I need to do a
> demo of something.  Is there a JIRA issue regarding this new feature, since
> I think this needs to be fleshed out more.
>
> On Tue Jan 06 2015 at 10:42:51 AM Andrew Grieve 
> wrote:
>
> > Mainly - it allows it to be installed alongside the release version of
> the
> > app.
> >
> > On Tue, Jan 6, 2015 at 11:01 AM, Brian LeRoux  wrote:
> >
> > > Why is it a good idea?
> > >
> > > On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve  wrote:
> > >
> > > > With gradle, this is easy to do:
> > > >
> > > > android {
> > > > buildTypes {
> > > > debug {
> > > > applicationIdSuffix ".debug"
> > > > }
> > > >
> > > > Seems like a good idea to me, but I'm wondering if there may be
> reason
> > > not
> > > > to?
> > > >
> > >
> >
>

[Vote] Tools Release Jan 6, 2015

[Steven Gill]

Please review and vote on this Tools Release.

Release issue: https://issues.apache.org/jira/browse/CB-8256

All tools have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8256/

The packages were published from their corresponding git tags:
cordova-js: 3.7.3 (8d6b736a36)
cordova-lib: 4.2.0 (52f7db9dfc)
cordova-plugman: 0.22.17 (016ef62e7e)
cordova-cli: 4.2.0 (afa8016230)

You can test the rc by going npm install -g cordova@rc.

I'd especially love if the windows and blackberry guys can test it!


Upon a successful vote I will upload the archives to dist/, publish
them to NPM, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
* ran unit tests + mobile spec on android + ios

RE: Cordova --list option implementation

[Murat Sutunc]

The feedback is definitely very valuable. I was trying to understand the issues 
with the existing design and once the impact is realized all the commits are 
immediately reversed.
I'm currently looking into your suggestions and will try to come up with a 
better design. 

-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com] 
Sent: Tuesday, January 6, 2015 10:40 AM
To: dev@cordova.apache.org
Subject: Re: Cordova --list option implementation

Parashuram wrote:
>Josh, is your concern that ‹list throws an error in case of blackberry?

No. my concern is that the way this was done was wrong .
It doesn't work for *ANY* project that exists today with *ANY* platform.

Cordova's design is to be backwards compatible. The code that was written
absolutely failed that.

I tried to hint at that in my review comments.

But that was totally ignored.

Note that list threw an error in android (@released) too (as Andrew
belatedly noted).

>We could fix that by either
>1a- Ignoring unknown flags like other platforms - and document the
>ignoring part as the default behavior

This is too late. You can't really change the behavior because
cordova-cli/cordova-lib needs to support old projects with old platforms.

>1b - or change other platforms to throw error on unsupported flags. In
>this case, ‹list would do the check to see if ‹list is implemented first.

You can't do this for the same reason that we can't do 1a.

>2. Implement ‹list for blackberry, thereby not having error on any
>platform. We could then have a separate discussion about what happens when
>a flag is not supported by a platform.

It's not specific to blackberry10, it applies to all existing platforms
which happen to have the underlying support but which shipped without an
imaginary change to run.js

>It would be great if we can let users use the ‹list functionality with
>minimal disruption to any platform.

Correct. And this is trivially done -- put the code into cordova-lib and
have it run the scripts from the platforms, instead of requiring changes
to platforms — they already did the work they need to do (they are free to
replace their existing impls w/ node.js impls if they haven't already, but
that's transparent to cordova-lib).

RE: Introduction

[Wargo, John]

Thanks Rob.

John M. Wargo

-Original Message-
From: Close, Rob [mailto:rob.cl...@sap.com]
Sent: Tuesday, January 6, 2015 10:33 AM
To: dev@cordova.apache.org
Subject: Introduction

Hello Cordova!

My initial interest is getting parts of Apache Cordova to pass HP Fortify scans.


Rob.

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

Re: Remove onDestroy event/channel from cordova-js

[Joe Bowser]

Are we sure the feature never worked? I'm not wanting to kill a feature to
find out that it worked on Android 2.x and that we broke someone's app.  I
think more testing is needed before we decide to kill it.

On Tue Jan 06 2015 at 4:57:25 PM Jesse  wrote:

> Well, if we find that the feature never worked, then we could just remove
> it.
>
> @purplecabbage
> risingj.com
>
> On Tue, Jan 6, 2015 at 4:52 PM, Joe Bowser  wrote:
>
> > This is an API change, and this would require a major version change for
> > both Android and CordovaJS.
> >
> > On Tue Jan 06 2015 at 4:50:17 PM Shazron  wrote:
> >
> > > Fine with me (iOS has no use of it)
> > >
> > > On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase 
> > wrote:
> > > > I'm working on CB-8210, to remove the use of javascript eval()s from
> > > native
> > > > code in cordova-android.  The goal is to pave the way for CSP.
> > > >
> > > > One usage was to fire the "onDestroy" event when the app is being
> > > > destroyed.  However, in my testing, I wasn't able to get this event
> > > firing
> > > > on the javascript side.  Upon investigation, I discovered that while
> > the
> > > > onDestroy is defined for all platforms (in channel.js), it is only
> > > > implemented for android.  Further, the code defines it as an internal
> > > > event, which should not be used in app code (guidance is to use
> > > > window.onunload instead).  I couldn't find any internal code using
> > > > onDestroy.
> > > >
> > > > Given the above, is there any reason to keep the onDestroy event?  It
> > > seems
> > > > the simplest thing to do is remove the event, rather than spending
> more
> > > > effort on getting it to work under CSP.  As well, it's defined as an
> > > > internal event, so I assume that removal would not be considered an
> API
> > > > change.
> > > >
> > > > I'd welcome any comments for/against removing onDestroy.
> > > >
> > > > Thanks,
> > > > Jason
> > > > Google Cordova team
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

Re: How to test the cordova-android 4.0 by mobile spec

[Joe Bowser]

I haven't been able to get mobile-spec working reliably since it was
refactored and we were forced to use the createmobilespec.sh script (i.e.
Tests don't run on Android 2.3) How did you manage to get it to work with
4.0.x?

On Tue Jan 06 2015 at 6:24:51 AM Andrew Grieve  wrote:

> I think you had it right. use cordova-mobile-spec@master and
> cordova-android@4.0.x. Failing tests are likely issues (in android or in
> the tests). Just fixed last night that the JS on 4.0.x was not properly
> registering with the CoreAndroid plugin due to it being renamed, so that
> could be the cause of the key event test failing.
>
> On Tue, Jan 6, 2015 at 3:47 AM, Fu, Junwei  wrote:
>
> > Hi,
> >
> > Because There are no cordova-mobile-spec  4.0 branch, so I used
> > cordova-mobile-spec master branch to test cordova-android 4.0, but the
> key
> > event test cases failed. And the splash screen test cases failed with
> > cordova-mobile-spec 3.6 branch, I don't know how to test the
> > cordova-android 4.0 by mobile spec.
> >
> > Thanks,
> > Junwei.
> >
>

Re: Remove onDestroy event/channel from cordova-js

[Jesse]

Well, if we find that the feature never worked, then we could just remove
it.

@purplecabbage
risingj.com

On Tue, Jan 6, 2015 at 4:52 PM, Joe Bowser  wrote:

> This is an API change, and this would require a major version change for
> both Android and CordovaJS.
>
> On Tue Jan 06 2015 at 4:50:17 PM Shazron  wrote:
>
> > Fine with me (iOS has no use of it)
> >
> > On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase 
> wrote:
> > > I'm working on CB-8210, to remove the use of javascript eval()s from
> > native
> > > code in cordova-android.  The goal is to pave the way for CSP.
> > >
> > > One usage was to fire the "onDestroy" event when the app is being
> > > destroyed.  However, in my testing, I wasn't able to get this event
> > firing
> > > on the javascript side.  Upon investigation, I discovered that while
> the
> > > onDestroy is defined for all platforms (in channel.js), it is only
> > > implemented for android.  Further, the code defines it as an internal
> > > event, which should not be used in app code (guidance is to use
> > > window.onunload instead).  I couldn't find any internal code using
> > > onDestroy.
> > >
> > > Given the above, is there any reason to keep the onDestroy event?  It
> > seems
> > > the simplest thing to do is remove the event, rather than spending more
> > > effort on getting it to work under CSP.  As well, it's defined as an
> > > internal event, so I assume that removal would not be considered an API
> > > change.
> > >
> > > I'd welcome any comments for/against removing onDestroy.
> > >
> > > Thanks,
> > > Jason
> > > Google Cordova team
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Auto-suffixing debug app id on Android

[Joe Bowser]

I don't think this idea is entirely thought out.  I've had debug and
release code on devices, and all it does is confuse me when I need to do a
demo of something.  Is there a JIRA issue regarding this new feature, since
I think this needs to be fleshed out more.

On Tue Jan 06 2015 at 10:42:51 AM Andrew Grieve 
wrote:

> Mainly - it allows it to be installed alongside the release version of the
> app.
>
> On Tue, Jan 6, 2015 at 11:01 AM, Brian LeRoux  wrote:
>
> > Why is it a good idea?
> >
> > On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve  wrote:
> >
> > > With gradle, this is easy to do:
> > >
> > > android {
> > > buildTypes {
> > > debug {
> > > applicationIdSuffix ".debug"
> > > }
> > >
> > > Seems like a good idea to me, but I'm wondering if there may be reason
> > not
> > > to?
> > >
> >
>

Re: Remove onDestroy event/channel from cordova-js

[Jesse]

same, seems onunload is more appropriate anyway, although devs can't expect
to do much in the time before all app resources are ripped away from them.

@purplecabbage
risingj.com

On Tue, Jan 6, 2015 at 4:47 PM, Shazron  wrote:

> Fine with me (iOS has no use of it)
>
> On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase  wrote:
> > I'm working on CB-8210, to remove the use of javascript eval()s from
> native
> > code in cordova-android.  The goal is to pave the way for CSP.
> >
> > One usage was to fire the "onDestroy" event when the app is being
> > destroyed.  However, in my testing, I wasn't able to get this event
> firing
> > on the javascript side.  Upon investigation, I discovered that while the
> > onDestroy is defined for all platforms (in channel.js), it is only
> > implemented for android.  Further, the code defines it as an internal
> > event, which should not be used in app code (guidance is to use
> > window.onunload instead).  I couldn't find any internal code using
> > onDestroy.
> >
> > Given the above, is there any reason to keep the onDestroy event?  It
> seems
> > the simplest thing to do is remove the event, rather than spending more
> > effort on getting it to work under CSP.  As well, it's defined as an
> > internal event, so I assume that removal would not be considered an API
> > change.
> >
> > I'd welcome any comments for/against removing onDestroy.
> >
> > Thanks,
> > Jason
> > Google Cordova team
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Remove onDestroy event/channel from cordova-js

[Joe Bowser]

This is an API change, and this would require a major version change for
both Android and CordovaJS.

On Tue Jan 06 2015 at 4:50:17 PM Shazron  wrote:

> Fine with me (iOS has no use of it)
>
> On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase  wrote:
> > I'm working on CB-8210, to remove the use of javascript eval()s from
> native
> > code in cordova-android.  The goal is to pave the way for CSP.
> >
> > One usage was to fire the "onDestroy" event when the app is being
> > destroyed.  However, in my testing, I wasn't able to get this event
> firing
> > on the javascript side.  Upon investigation, I discovered that while the
> > onDestroy is defined for all platforms (in channel.js), it is only
> > implemented for android.  Further, the code defines it as an internal
> > event, which should not be used in app code (guidance is to use
> > window.onunload instead).  I couldn't find any internal code using
> > onDestroy.
> >
> > Given the above, is there any reason to keep the onDestroy event?  It
> seems
> > the simplest thing to do is remove the event, rather than spending more
> > effort on getting it to work under CSP.  As well, it's defined as an
> > internal event, so I assume that removal would not be considered an API
> > change.
> >
> > I'd welcome any comments for/against removing onDestroy.
> >
> > Thanks,
> > Jason
> > Google Cordova team
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Remove onDestroy event/channel from cordova-js

[Shazron]

Fine with me (iOS has no use of it)

On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase  wrote:
> I'm working on CB-8210, to remove the use of javascript eval()s from native
> code in cordova-android.  The goal is to pave the way for CSP.
>
> One usage was to fire the "onDestroy" event when the app is being
> destroyed.  However, in my testing, I wasn't able to get this event firing
> on the javascript side.  Upon investigation, I discovered that while the
> onDestroy is defined for all platforms (in channel.js), it is only
> implemented for android.  Further, the code defines it as an internal
> event, which should not be used in app code (guidance is to use
> window.onunload instead).  I couldn't find any internal code using
> onDestroy.
>
> Given the above, is there any reason to keep the onDestroy event?  It seems
> the simplest thing to do is remove the event, rather than spending more
> effort on getting it to work under CSP.  As well, it's defined as an
> internal event, so I assume that removal would not be considered an API
> change.
>
> I'd welcome any comments for/against removing onDestroy.
>
> Thanks,
> Jason
> Google Cordova team

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

Re: Automated builds / tests for plugins

[Shazron]

Hi Erik,
We've been using cordova-mobile-spec, and a script to install all the
tests: 
https://github.com/apache/cordova-mobile-spec/tree/master/createmobilespec
(based off the dependencies-plugin in that same repo). The README in
that folder should have more information.

On Tue, Jan 6, 2015 at 10:10 AM, Erik Brommers  wrote:
> Hello,
>
> I'm in the process of writing a plugin that might be worth including
> in the general cordova plugin set (getting info about the installed
> fonts on a device). I've been trying to follow the general structure
> of the cordova plugins, but haven't come across information about how
> the automated builds / test scripts are kicked off yet. If someone
> could point be in the right direction, I'd very much appreciate it.
>
> Thanks!
>
> Erik
>
> PS - I've gotten the cordova-plugin-test-framework up and running. I'm
> just wondering how the plugins are built, if there's an automated
> build system. Grunt? Something else? Any info would be helpful.
>
> -
> 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

[iOS][Camera] Re-factor so it is testable

[Shazron]

FYI.

I've done all the work [1], including adding native unit-tests [2].
The auto tests and manual tests I've done in mobile-spec pass,
including my new unit-tests which only has 3 failures, which is
expected [3].

I'll merge/squash the pull requests within the next few days.

This re-factor was sorely needed because the code has become a
spaghetti mishmash and new pull requests coming in could not be easily
verified that it does not break anything, and the unit tests are
needed for another bug-fix [3]

[1] https://github.com/apache/cordova-plugin-camera/pull/52
[2] https://github.com/apache/cordova-plugin-camera/pull/60
[3] https://issues.apache.org/jira/browse/CB-5942

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

What's up with travis-ci ?

[Mefire O .]

I've been waiting on this Travis CI build for the past 2 hours.
Anybody has any idea on what's going on ?

https://travis-ci.org/apache/cordova-lib/builds/46130131

Re: Cordova-lib failing on master (stopping release)

[Steven Gill]

Yup. I reverted to that commit. Pushed to master. Continuing with release.

On Tue, Jan 6, 2015 at 2:46 PM, Mark Koudritsky  wrote:

> This commit
>
> https://github.com/apache/cordova-lib/commit/b2e33f55e98f23116066f47f9b6ea5b49474d95c
> passed on both AppVeyor
>  and
> Travis 
>

Re: Cordova-lib failing on master (stopping release)

[Mark Koudritsky]

This commit
https://github.com/apache/cordova-lib/commit/b2e33f55e98f23116066f47f9b6ea5b49474d95c
passed on both AppVeyor
 and
Travis 

Re: Introduction

[Shazron]

Welcome Rob, let us know how we can help if needed.

http://www8.hp.com/ca/en/software-solutions/software-security-assurance-sdlc/

On Tue, Jan 6, 2015 at 7:33 AM, Close, Rob  wrote:
> Hello Cordova!
>
> My initial interest is getting parts of Apache Cordova to pass HP Fortify 
> scans.
>
>
> Rob.

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

[GitHub] cordova-plugin-file-transfer pull request: CB-8095 Adds support fo...

[purplecabbage]

Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/53#issuecomment-68943489
  
@vladimir-kotikov This looks good. Can you rebase for me and I'll test some 
more?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-lib pull request: CB-8226 'cordova platform add' : Look up...

[omefire]

Github user omefire commented on the pull request:

https://github.com/apache/cordova-lib/pull/140#issuecomment-68942932
  
Working on it ...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-file-transfer pull request: wp8 cleanUrl needs rela...

[purplecabbage]

Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/26#issuecomment-68938883
  
merged


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Cordova-lib failing on master (stopping release)

[Jesse]

Yes please do.
This type of work should be done in a branch, and at least smoke tested on
windows+mac before being pushed.
It is also broken in appveyor tests, although that seems like it might be
an issue with the commit before.

@purplecabbage
risingj.com

On Tue, Jan 6, 2015 at 1:22 PM, Steven Gill  wrote:

> Commit:
>
> https://github.com/apache/cordova-lib/commit/197c49a1727fab676543595867aa3557966f7d12
>
> Travis:
>
> https://github.com/apache/cordova-lib/commit/197c49a1727fab676543595867aa3557966f7d12
>
> I am going to revert this commit unless you guys think it is necessary. If
> so, we need to fix these tests ASAP so I can continue release.
>
> -Steve
>

[GitHub] cordova-lib pull request: CB-8226 'cordova platform add' : Look up...

[agrieve]

Github user agrieve commented on the pull request:

https://github.com/apache/cordova-lib/pull/140#issuecomment-68936506
  
Looks good I think. Just tried to pull it in and there are many merge 
conflicts unfortunately. Would you be able to rebase?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-file-transfer pull request: CB-2332 Document "body"...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-file-transfer/pull/56


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Cordova-lib failing on master (stopping release)

[Steven Gill]

Commit:
https://github.com/apache/cordova-lib/commit/197c49a1727fab676543595867aa3557966f7d12

Travis:
https://github.com/apache/cordova-lib/commit/197c49a1727fab676543595867aa3557966f7d12

I am going to revert this commit unless you guys think it is necessary. If
so, we need to fix these tests ASAP so I can continue release.

-Steve

[Code Review] Gradle Changes

[Andrew Grieve]

For anyone following the gradle work that's been happening, I have a PR
that overhauls how settings are overridden. Rather than using custom
environment variables, it uses Gradle properties. This is exactly what
properties in gradle were designed for, and they are more flexible.

I'd like 2 things:
1 - Code review for https://github.com/apache/cordova-android/pull/145 (Ian
- mostly looking at you :P)
2 - Comments about whether there is a need to continue supporting the
existing environment variables. Given that gradle is not enabled by
default, and marked as experimental, I think they are fine to just change.

[GitHub] cordova-android pull request: CB-8255 Use properties rather than e...

[agrieve]

GitHub user agrieve opened a pull request:

https://github.com/apache/cordova-android/pull/145

CB-8255 Use properties rather than environment variables for gradle settings

For review. I'll merge in if it's good to go!

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agrieve/cordova-android gradle-props

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-android/pull/145.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #145


commit 2ddebd36dd866eb3e3e298a03cc943d7f334a5c4
Author: Andrew Grieve 
Date:   2015-01-06T20:56:09Z

CB-8255 Use properties rather than environment variables for gradle settings




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: Add Media.prototype.setRate met...

[whitecolor]

Github user whitecolor commented on the pull request:

https://github.com/apache/cordova-plugin-media/pull/40#issuecomment-68928992
  
Ok, I've added, if ok with this check, how it is going to be tested?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: Add Media.prototype.setRate met...

[purplecabbage]

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-plugin-media/pull/40#issuecomment-68922902
  
For now just go back to ```Media.prototype.setRate = function(rate) { ...```
But add the check for ios, to prevent crashing on platforms that do not 
implement it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: Add Media.prototype.setRate met...

[whitecolor]

Github user whitecolor commented on the pull request:

https://github.com/apache/cordova-plugin-media/pull/40#issuecomment-68920774
  
Do what would you sugget to do with ```playbackRate```? create method 
```setPlaybackRate``` (insteald of ```setRate```) or what? in HTML audio's 
```playbackRate``` actually JS getter/setter.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-contacts pull request: Windows phone contact picker...

[purplecabbage]

Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-contacts/pull/51#issuecomment-68919056
  
Hi @Hurtyto 
This looks good. Have you signed the CLA?
I cannot find your github username, or parts of your email address listed 
on https://people.apache.org/committer-index.html
Note, It would also be helpful if you could add your name to your github 
profile

More info on contributing here: http://cordova.apache.org/#contribute



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-contacts pull request: CB-4612 Update ContactName s...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-contacts/pull/52


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-lib pull request: CB-8226 'cordova platform add' : Look up...

[omefire]

Github user omefire commented on the pull request:

https://github.com/apache/cordova-lib/pull/140#issuecomment-68916510
  
Done! 'file://' prefix support dropped. :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: Add Media.prototype.setRate met...

[purplecabbage]

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-plugin-media/pull/40#issuecomment-68914636
  
Yeah, ```playbackRate``` is the right choice then.  Following the HTML5 
audio element spec is more important than my alternative suggestion.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: CB-8248 Translation contains unnecessar...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/254


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: CB-8246 Improve docs generation time

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/253


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Auto-suffixing debug app id on Android

[Andrew Grieve]

Mainly - it allows it to be installed alongside the release version of the
app.

On Tue, Jan 6, 2015 at 11:01 AM, Brian LeRoux  wrote:

> Why is it a good idea?
>
> On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve  wrote:
>
> > With gradle, this is easy to do:
> >
> > android {
> > buildTypes {
> > debug {
> > applicationIdSuffix ".debug"
> > }
> >
> > Seems like a good idea to me, but I'm wondering if there may be reason
> not
> > to?
> >
>

[GitHub] cordova-lib pull request: CB-8226 'cordova platform add' : Look up...

[agrieve]

Github user agrieve commented on the pull request:

https://github.com/apache/cordova-lib/pull/140#issuecomment-68910601
  
I agree that's some unnecessary complexity. Let's just drop supporting of 
file: prefix.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Cordova --list option implementation

[Josh Soref]

Parashuram wrote:
>Josh, is your concern that ‹list throws an error in case of blackberry?

No. my concern is that the way this was done was wrong .
It doesn't work for *ANY* project that exists today with *ANY* platform.

Cordova's design is to be backwards compatible. The code that was written
absolutely failed that.

I tried to hint at that in my review comments.

But that was totally ignored.

Note that list threw an error in android (@released) too (as Andrew
belatedly noted).

>We could fix that by either
>1a- Ignoring unknown flags like other platforms - and document the
>ignoring part as the default behavior

This is too late. You can't really change the behavior because
cordova-cli/cordova-lib needs to support old projects with old platforms.

>1b - or change other platforms to throw error on unsupported flags. In
>this case, ‹list would do the check to see if ‹list is implemented first.

You can't do this for the same reason that we can't do 1a.

>2. Implement ‹list for blackberry, thereby not having error on any
>platform. We could then have a separate discussion about what happens when
>a flag is not supported by a platform.

It's not specific to blackberry10, it applies to all existing platforms
which happen to have the underlying support but which shipped without an
imaginary change to run.js

>It would be great if we can let users use the ‹list functionality with
>minimal disruption to any platform.

Correct. And this is trivially done -- put the code into cordova-lib and
have it run the scripts from the platforms, instead of requiring changes
to platforms — they already did the work they need to do (they are free to
replace their existing impls w/ node.js impls if they haven't already, but
that's transparent to cordova-lib).


smime.p7s
Description: S/MIME cryptographic signature

[GitHub] cordova-lib pull request: CB-8226 'cordova platform add' : Look up...

[omefire]

Github user omefire commented on the pull request:

https://github.com/apache/cordova-lib/pull/140#issuecomment-68909782
  
Using url.parse introduces additional complexity. Especially, Windows paths 
are not going to be handled properly: the drive letter gets omitted after 
parsing. This leads to more confusion for the user.
Linux/Unix absolute paths would be handled appropriately, but Windows's 
wouldn't.

I suggest we remove the file:// prefix and not make config.xml contain urls 
for folder paths.
Take the following examples:
1-  url.parse('file://D:/Cordova/cordova-lib') => 
{ 
  protocol: 'file:',
  slashes: true,
  auth: null,
  host: 'd',
  port: null,
  hostname: 'd',
  hash: null,
  search: null,
  query: null,
  pathname: '/Cordova/cordova-lib',
  path: '/Cordova/cordova-lib',
  href: 'file://d/Cordova/cordova-lib' 
}

2- url.parse('file://D:\Cordova\cordova-lib') => 
{ 
  protocol: 'file:',
  slashes: true,
  auth: null,
  host: 'd',
  port: null,
  hostname: 'd',
  hash: null,
  search: null,
  query: null,
  pathname: '/:Cordovacordova-lib',
  path: '/:Cordovacordova-lib',
  href: 'file://d/:Cordovacordova-lib' 
}

3- url.parse('file:///Cordova/cordova-lib') =>
{ 
  protocol: 'file:',
  slashes: true,
  auth: null,
  host: '',
  port: null,
  hostname: '',
  hash: null,
  search: null,
  query: null,
  pathname: '/Cordova/cordova-lib',
  path: '/Cordova/cordova-lib',
  href: 'file:///Cordova/cordova-lib' 
}

So, my suggestion is to only support plain filesystem paths for folders in 
config.xml.
What do you think ?



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Automated builds / tests for plugins

[Erik Brommers]

Hello,

I'm in the process of writing a plugin that might be worth including
in the general cordova plugin set (getting info about the installed
fonts on a device). I've been trying to follow the general structure
of the cordova plugins, but haven't come across information about how
the automated builds / test scripts are kicked off yet. If someone
could point be in the right direction, I'd very much appreciate it.

Thanks!

Erik

PS - I've gotten the cordova-plugin-test-framework up and running. I'm
just wondering how the plugins are built, if there's an automated
build system. Grunt? Something else? Any info would be helpful.

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

Re: Documentation generation in pure Node.JS

[Marcel Kinard]

Woohoo!

> On Thu, Dec 25, 2014 at 12:02 AM, Andrey Kurdumov 
> wrote:
> 
>> README.md updated and Ruby files deleted.
>> Also create script which should replace Rakefile in case if somebody need
>> it.


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

Re: [DISCUSS] Tools Release

[Steven Gill]

I will begin the process today!

-Steve

On Mon, Jan 5, 2015 at 7:16 PM, Parashuram N (MS OPEN TECH) <
panar...@microsoft.com> wrote:

> +1 to removing that specific commit and continuing with the release
> process. I have also forked this thread where we should continue the
> discussion (so as not to overload the DISCUSS thread).
>
> On 1/5/15, 6:43 PM, "Andrew Grieve"  wrote:
>
> >Josh - thanks for pointing out that the change isn't working as intended.
> >I
> >did some testing before merging, but didn't try the error conditions.
> >
> >I've just reverted the one to CLI that enables the flag. Let's move
> >forward
> >with releasing :)
> >
> >Also noticed that if you have an older-than-master version of android
> >installed in your project, then you get:
> >
> >$ cordova run --list
> >Running command:
> >/Users/agrieve/git/cordova/cordova-cli/foo/platforms/android/cordova/run
> >--list
> >ERROR : Run option '--list' not recognized.
> >ERROR running one or more of the platforms: Error:
> >/Users/agrieve/git/cordova/cordova-cli/foo/platforms/android/cordova/run:
> >Command failed with exit code 2
> >You may not have the required environment or OS to run this project
> >
> >I actually do like the syntax of "cordova run --list", since the run
> >command is the thing that --target is relevant to anyways. Maybe
> >"--list-targets" would be more explicit? Adding  "cordova target add"
> >would
> >be overstepping I think. You can add Android emulator targets as well, but
> >us writing a wrapper for the logic would just make things more complicated
> >I think.
> >
> >I do think that having cordova-lib look for the existence of
> >the list-emulator-images and list-devices scripts makes sense, and just
> >have it call them directly.
> >
> >
> >On Mon, Jan 5, 2015 at 5:29 PM, Josh Soref  wrote:
> >
> >> Murat Sutunc wrote:
> >> >1) When provided with an unknown extra parameter, such as --list in
> >>this
> >> >case, all the platforms ignore it. This looks like the expected
> >>behavior
> >> >as there are several issues in Jira related to it. (ex. See bug
> >>CB-6676 -
> >> >
> >>
> >>
> https://issues.apache.org/jira/browse/CB-6676?jql=project%20%3D%20CB%20AN
> >>D
> >> >%20text%20~%20%22ignore%20parameter%22). Exit code 1 on Blackberry
> >>seems
> >> >like a bug.
> >>
> >> https://wiki.apache.org/cordova/CommandLineToolingDesign#Errors
> >>
> >>
> >> * 1: not implemented / unsupported command
> >>
> >>
> >> I believe that what windows phone was doing was correct. And if someone
> >>is
> >> changing the contract, they failed to update the contract.
> >>
> >> >
> >> >2) Introducing 'target' as a top level option seems like a new
> >>proposal.
> >> >My thoughts were to avoid having a new top level command for listing
> >> >devices but I would like to hear others opinions on this as well. I
> >>also
> >> >think 'target' might not be the best choice of keyword here as it's
> >> >already part of 'run' and it's easy to get confused:
> >> >   cordova run --target=FOO
> >> >   cordova target --list
> >>
> >> Not --list, just plain "list". As in "cordova platform list", and
> >>"cordova
> >> plugin list", it's a commonly used idiom in cordova.
> >>
> >> >3) I don¹t understand the 'cordova target add' command completely. Is
> >>it
> >> >an alias to 'cordova platform add'?
> >>
> >> No.
> >>
> >> For blackberry10 you can configure a "target" which is a name for a set
> >>of
> >> settings (including an ip address/dns name, whether it is a
> >> device/simulator, and a device password). You can then use run
> >> --target=foo.
> >>
> >> >4) 'Each platform should already support the list-* commands' is
> >> >currently not true. firefoxos, browser, Ubuntu don¹t support it.
> >>
> >> Those platforms aren't complete, it's part of the contract, but we
> >>already
> >> have a good way of handling missing components of lib/ ‹ if they don't
> >> exist (we can check for this), or aren't implemented (they return a
> >> standard value).
> >>
> >> The way you've implemented it with run, there's no way to look before
> >>you
> >> leap, which results in the failure that you introduced for blackberry10.
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

[GitHub] cordova-plugin-device pull request: Internet Explorer browser supp...

[BigstickCarpet]

Github user BigstickCarpet commented on the pull request:


https://github.com/apache/cordova-plugin-device/pull/28#issuecomment-68895043
  
What is the planned release date for this fix?  `cordova plugin add 
org.apache.cordova.device` still gets the version without the fix, so it still 
doesn't work in IE.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Auto-suffixing debug app id on Android

[Brian LeRoux]

Why is it a good idea?

On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve  wrote:

> With gradle, this is easy to do:
>
> android {
> buildTypes {
> debug {
> applicationIdSuffix ".debug"
> }
>
> Seems like a good idea to me, but I'm wondering if there may be reason not
> to?
>

Introduction

[Close, Rob]

Hello Cordova!

My initial interest is getting parts of Apache Cordova to pass HP Fortify scans.


Rob.

Auto-suffixing debug app id on Android

[Andrew Grieve]

With gradle, this is easy to do:

android {
buildTypes {
debug {
applicationIdSuffix ".debug"
}

Seems like a good idea to me, but I'm wondering if there may be reason not
to?

Re: How to test the cordova-android 4.0 by mobile spec

[Andrew Grieve]

I think you had it right. use cordova-mobile-spec@master and
cordova-android@4.0.x. Failing tests are likely issues (in android or in
the tests). Just fixed last night that the JS on 4.0.x was not properly
registering with the CoreAndroid plugin due to it being renamed, so that
could be the cause of the key event test failing.

On Tue, Jan 6, 2015 at 3:47 AM, Fu, Junwei  wrote:

> Hi,
>
> Because There are no cordova-mobile-spec  4.0 branch, so I used
> cordova-mobile-spec master branch to test cordova-android 4.0, but the key
> event test cases failed. And the splash screen test cases failed with
> cordova-mobile-spec 3.6 branch, I don't know how to test the
> cordova-android 4.0 by mobile spec.
>
> Thanks,
> Junwei.
>

[GitHub] cordova-docs pull request: CB-8248 Translation contains unnecessar...

[kant2002]

GitHub user kant2002 opened a pull request:

https://github.com/apache/cordova-docs/pull/254

CB-8248 Translation contains unnecessary files

Remove translation files which was left when moving plugin documentation to 
plugin repos

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kant2002/cordova-docs CB-8248

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-docs/pull/254.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #254


commit cca78ce48009c87fa9bc836b0630f9282fefac3e
Author: Andrey Kurdyumov 
Date:   2015-01-05T22:13:06Z

Merge pull request #1 from apache/master

Merge with upstream

commit 0d8a50448032b6ddf90697117e61ff104c4709ed
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:21:07Z

Remove not used files in German translation

commit e12ae4a7001d57f550e6277f7a0aaac8cbb60067
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:21:55Z

Remove not used files in French translation

commit 5a84e292f1214e3da249d39e68dda8e713767426
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:22:16Z

Remove not used files in Italian translation

commit eb6a75b866a5569af7d8c7a97f76145ad2c09315
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:22:50Z

Remove not used files in Spanish translation

commit 567d963e624a0947f24b361bb00fdcfdf1a50ddb
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:23:18Z

Remove not used files in Japanese translation

commit 7221bb60a1050b8f1cba0df4c2b3aa0ad8743c48
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:24:13Z

Remove not used files in Korean translation

commit 604a4cc2dde9b7bec54755c05a821a14bb3dd407
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:24:29Z

Remove not used files in Chinese translation

commit 991566d93ceb29287e8874f2912ba8da97e4e488
Author: Andrey Kurdyumov 
Date:   2015-01-06T12:24:43Z

Remove not used files in Russian translation




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: Add Media.prototype.setRate met...

[whitecolor]

Github user whitecolor commented on the pull request:

https://github.com/apache/cordova-plugin-media/pull/40#issuecomment-68854223
  
@purplecabbage Well I think the variant with playbackRate option for 
```play``` maybe ok but lets consider this most of the platforms treats 
playback rate just like ```volume``` property, that can be changed at any time:

1) HTML5 audio supports just a property ```playbackRate``` on ```audio``` 
element, that you can set anytime while playing.

2) iOs supports ```setRate``` method on ```AVAudioPlayer``` object (to can 
be set while 
playing).(https://developer.apple.com/library/ios/documentation/AVFoundation/Reference/AVAudioPlayerClassReference/index.html)

3) Windows Phone supports ```SpeedRatio``` property on ```MediaElement``` 
(http://msdn.microsoft.com/en-us/library/system.windows.controls.mediaelement.speedratio(v=vs.110).aspx)

4) The problem with android: phonegap uses ```MediaPlayer``` for playing 
media files, but it does not support any rate change methods (an old issue 
https://code.google.com/p/android/issues/detail?id=1961), there is also 
```AudioTrack``` class, that can be used to play media, and probably have some 
capabilities of chanding rate (need to be tested) but there is a problem with 
seeking and actually it plays only uncompressed audio (that can be taken from 
```MediaPlayer``` - so the workflow with using ```AudioTrack``` is quite 
complicated). The is also ```SoundPool``` class that has method ```setRate```, 
but it has the same problems that ```AudioTrack``` class. But actually people 
do implement such capabilities in android (in different audiobooks playing 
applicatons).

So I think it is reasonable to approach to ```payback rate``` just as to 
```volume``` property, and as PG has method ```setVolume``` and had proposed 
```setRate``` for this. What do you think?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-vibration pull request: Update index.md

[HirofumiTamori]

GitHub user HirofumiTamori opened a pull request:

https://github.com/apache/cordova-plugin-vibration/pull/31

Update index.md

Correct Japanese translation and corrupted API description due to automatic 
translation.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/HirofumiTamori/cordova-plugin-vibration 
patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-vibration/pull/31.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #31


commit 2d354f7d3daccbd1f852c7464fd507efe7227401
Author: Hirofumi Tamori 
Date:   2015-01-06T10:39:31Z

Update index.md

Correct Japanese translation and corrupted API description due to automatic 
translation.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

RE: [Vote] 3.7.1 WP8 Release

[Sergey Grebnov (Akvelon)]

Thank you a lot, Steve. The package has been published.

-Sergey
-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Monday, January 5, 2015 10:30 PM
To: dev@cordova.apache.org
Subject: Re: [Vote] 3.7.1 WP8 Release

Added you as a owner on npm

On Mon, Jan 5, 2015 at 11:25 AM, Sergey Grebnov (Akvelon) < 
v-seg...@microsoft.com> wrote:

> Hi guys,
>
> Could someone grand me w/ write access to npm[2] or publish release 
> package[1]?
>
> [1]
> https://dist.apache.org/repos/dist/dev/cordova/CB-8179/cordova-wp8-3.7
> .1.tgz [2] https://www.npmjs.com/package/cordova-wp8
>
> Thx!
> Sergey
> -Original Message-
> From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com]
> Sent: Monday, December 22, 2014 11:09 PM
> To: dev@cordova.apache.org
> Subject: RE: [Vote] 3.7.1 WP8 Release
>
> Uploaded release archives to dist, could someone publish release 
> package[1] to npm or grand me with required  permissions (I've just 
> realized I have access to cordova-windows only).
>
> [1]
> https://dist.apache.org/repos/dist/dev/cordova/CB-8179/cordova-wp8-3.7
> .1.tgz [2] https://www.npmjs.com/package/cordova-wp8
>
> Thx!
> Sergey
> -Original Message-
> From: Sergey Grebnov (Akvelon)
> Sent: Monday, December 22, 2014 10:58 PM
> To: dev@cordova.apache.org
> Subject: RE: [Vote] 3.7.1 WP8 Release
>
> The vote has now closed. The results are:
>
> Positive Binding Votes: 4
> Steve Gill
> Parashuram Narasimhan
> Vladimir Kotikov
> Sergey Grebnov
>
> Negative Binding Votes: 0
>
> The vote has passed.
>
> I will publish to dist + npm later today.
>
> Thx!
> Sergey
> -Original Message-
> From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
> Sent: Monday, December 22, 2014 11:38 AM
> To: dev@cordova.apache.org
> Subject: RE: [Vote] 3.7.1 WP8 Release
>
> I vote +1:
>
> * ran mobilespec to ensure that platform is being added, built and 
> deployed successfully
>
> ---
> Best regards, Vladimir
>
> -Original Message-
> From: Parashuram Narasimhan (MS OPEN TECH) 
> [mailto:panar...@microsoft.com]
> Sent: Saturday, 20 December, 2014 2:47
> To: dev@cordova.apache.org
> Subject: RE: [Vote] 3.7.1 WP8 Release
>
> +1
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Friday, December 19, 2014 11:40 AM
> To: dev@cordova.apache.org
> Subject: Re: [Vote] 3.7.1 WP8 Release
>
> +1
>
> Verified archive
>
> On Thu, Dec 18, 2014 at 4:44 AM, Sergey Grebnov (Akvelon) < 
> v-seg...@microsoft.com> wrote:
> >
> > Please review and vote on this 3.7.1 WP8 Release.
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-8179
> >
> > Repos ready to be released have been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/CB-8179
> >
> > The package was published from its corresponding git tag: fb6796796b
> >
> > Upon a successful vote I will upload the archive to dist/, publish 
> > it to NPM, and post the corresponding blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voti
> > ng
> > .md
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and 
> > subdependencies have Apache-compatible licenses
> > * Performed manual tests to ensure platform could be successfully 
> > built and run
> >
> > Thx!
> > Sergey
> >
> > 
> > - 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
>
>

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

RE: Cordova --list option implementation

[Sergey Grebnov (Akvelon)]

In case of 1a "Ignoring unknown flags" approach I would also warn for each 
unknown parameter.

-Sergey
-Original Message-
From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] 
Sent: Tuesday, January 6, 2015 6:22 AM
To: dev
Subject: Cordova --list option implementation

Forking from Re: [DISCUSS] Tools Release to continue discussion.

+1 to Andrew suggestion that adding a top level command just for listing
targets would be an overkill. Also, people usually want to see the supported 
targets when they run, so it makes sense to expose it closer to where it gets 
used.

If we decide that cordova target add could be used to create new targets, that 
could be a separate top level command, can `cordova run  wrote:

>Josh - thanks for pointing out that the change isn't working as intended.
>I
>did some testing before merging, but didn't try the error conditions.
>
>I've just reverted the one to CLI that enables the flag. Let's move 
>forward with releasing :)
>
>Also noticed that if you have an older-than-master version of android 
>installed in your project, then you get:
>
>$ cordova run --list
>Running command:
>/Users/agrieve/git/cordova/cordova-cli/foo/platforms/android/cordova/ru
>n
>--list
>ERROR : Run option '--list' not recognized.
>ERROR running one or more of the platforms: Error:
>/Users/agrieve/git/cordova/cordova-cli/foo/platforms/android/cordova/run:
>Command failed with exit code 2
>You may not have the required environment or OS to run this project
>
>I actually do like the syntax of "cordova run --list", since the run 
>command is the thing that --target is relevant to anyways. Maybe 
>"--list-targets" would be more explicit? Adding  "cordova target add"
>would
>be overstepping I think. You can add Android emulator targets as well, 
>but us writing a wrapper for the logic would just make things more 
>complicated I think.
>
>I do think that having cordova-lib look for the existence of the 
>list-emulator-images and list-devices scripts makes sense, and just 
>have it call them directly.
>
>
>On Mon, Jan 5, 2015 at 5:29 PM, Josh Soref  wrote:
>
>> Murat Sutunc wrote:
>> >1) When provided with an unknown extra parameter, such as --list in
>>this
>> >case, all the platforms ignore it. This looks like the expected
>>behavior
>> >as there are several issues in Jira related to it. (ex. See bug
>>CB-6676 -
>> >
>> 
>>https://issues.apache.org/jira/browse/CB-6676?jql=project%20%3D%20CB%2
>>0AN
>>D
>> >%20text%20~%20%22ignore%20parameter%22). Exit code 1 on Blackberry
>>seems
>> >like a bug.
>>
>> https://wiki.apache.org/cordova/CommandLineToolingDesign#Errors
>>
>>
>> * 1: not implemented / unsupported command
>>
>>
>> I believe that what windows phone was doing was correct. And if 
>>someone is  changing the contract, they failed to update the contract.
>>
>> >
>> >2) Introducing 'target' as a top level option seems like a new
>>proposal.
>> >My thoughts were to avoid having a new top level command for listing 
>> >devices but I would like to hear others opinions on this as well. I
>>also
>> >think 'target' might not be the best choice of keyword here as it's 
>> >already part of 'run' and it's easy to get confused:
>> >   cordova run --target=FOO
>> >   cordova target --list
>>
>> Not --list, just plain "list". As in "cordova platform list", and 
>>"cordova  plugin list", it's a commonly used idiom in cordova.
>>
>> >3) I don¹t understand the 'cordova target add' command completely. 
>> >Is
>>it
>> >an alias to 'cordova platform add'?
>>
>> No.
>>
>> For blackberry10 you can configure a "target" which is a name for a 
>>set of  settings (including an ip address/dns name, whether it is a  
>>device/simulator, and a device password). You can then use run  
>>--target=foo.
>>
>> >4) 'Each platform should already support the list-* commands' is 
>> >currently not true. firefoxos, browser, Ubuntu don¹t support it.
>>
>> Those platforms aren't complete, it's part of the contract, but we 
>>already  have a good way of handling missing components of lib/ < if 
>>they don't  exist (we can check for this), or aren't implemented (they 
>>return a  standard value).
>>
>> The way you've implemented it with run, there's no way to look before 
>>you  leap, which results in the failure that you introduced for 
>>blackberry10.
>>


-
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

[GitHub] cordova-plugin-contacts pull request: Fix for CB-4946

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-contacts/pull/53


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

How to test the cordova-android 4.0 by mobile spec

[Fu, Junwei]

Hi,

Because There are no cordova-mobile-spec  4.0 branch, so I used 
cordova-mobile-spec master branch to test cordova-android 4.0, but the key 
event test cases failed. And the splash screen test cases failed with 
cordova-mobile-spec 3.6 branch, I don't know how to test the cordova-android 
4.0 by mobile spec.

Thanks,
Junwei.