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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
Fine with me (iOS has no use of it)
On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase cha...@chromium.org 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
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 shaz...@gmail.com wrote:
Fine with me (iOS has no use of it)
On Mon, Jan 5, 2015 at 12:27 PM, Jason Chase cha...@chromium.org wrote:
I'm working on
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 agri...@chromium.org
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 purplecabb...@gmail.com wrote:
Well, if we find
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
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
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 shaz...@gmail.com wrote:
Fine with me (iOS has no use of it)
On Mon, Jan
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
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
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
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
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
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:
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,
This commit
https://github.com/apache/cordova-lib/commit/b2e33f55e98f23116066f47f9b6ea5b49474d95c
passed on both AppVeyor
https://ci.appveyor.com/project/Humbedooh/cordova-lib/build/1.0.333 and
Travis https://travis-ci.org/apache/cordova-lib/builds/45818232
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,
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 bows...@gmail.com wrote:
Are we sure the
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 agri...@chromium.org wrote:
I've just been checkout out 4.0.x branch of cordova-android, then running
the script. I think the script requires that
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 bows...@gmail.com wrote:
I haven't been able to get
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.
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
Gar, thanks for reverting and moving on. Sorry for not running tests :(
On Tue, Jan 6, 2015 at 5:54 PM, Steven Gill stevengil...@gmail.com wrote:
Yup. I reverted to that commit. Pushed to master. Continuing with release.
On Tue, Jan 6, 2015 at 2:46 PM, Mark Koudritsky kam...@google.com 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 agri...@chromium.org wrote:
Nope no JIRA, just something I stumbled across when I was reading gradle
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,
Hello Cordova!
My initial interest is getting parts of Apache Cordova to pass HP Fortify scans.
Rob.
So two apps, same name on the springboard/deck, but diff id?
On Tue, Jan 6, 2015, 7:46 PM Tommy Williams to...@devgeeks.org 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
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,
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
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,
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
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 b...@brian.io wrote:
Why is it a good idea?
On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve agri...@google.com wrote:
With gradle, this is easy to do:
android {
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
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 PERIOD.
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
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
Why is it a good idea?
On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve agri...@google.com 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
Woohoo!
On Thu, Dec 25, 2014 at 12:02 AM, Andrey Kurdumov kant2...@googlemail.com
wrote:
README.md updated and Ruby files deleted.
Also create script which should replace Rakefile in case if somebody need
it.
-
To
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
57 matches
Mail list logo
