[GitHub] cordova-medic pull request: CB-8045 Fixed wrong name of activity t...
Github user dmitriy-barkalov commented on the pull request: https://github.com/apache/cordova-medic/pull/20#issuecomment-67630421 Could anybody review it please --- 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-device-motion pull request: CB-8096 Pended auto tes...
Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-plugin-device-motion/pull/22#issuecomment-67637571 reviewed and merged to master --- 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: How to handle CSP for XHR in Cordova 4.0
On Thu Dec 18 2014 at 9:42:18 AM Andrew Grieve wrote: > That's a good point Chuck. Since the meaning of would be changing > in a dramatic way, I think we should just come up with something new, and > leave for anyone that wants to use the legacy-whitelist plugin. > > Maybe: > PATTERN > PATTERN > > On Wed, Dec 17, 2014 at 5:29 PM, Chuck Lantz wrote: > > > > Yeah, I also am thinking about "upgrade" situations where someone takes > an > > existing app and moves it to Android Cordova 4.0. It strikes me there > we'd > > either want the existing behavior to be preserved (flaws aside) or move > it > > to the top level nav behavior. Did I read correctly the current > whitelist > > would be refactored out to a plugin? > And yes, the current whitelist, flaws and all, is refactored out into org.apache.cordova.legacy-whitelist. The source is in the cordova-plugins repo; it hasn't been published yet. Ian > > > > -Chuck > > > > -Original Message- > > From: Ian Clelland [mailto:iclell...@chromium.org] > > Sent: Wednesday, December 17, 2014 1:02 PM > > To: dev@cordova.apache.org > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > I think that access tags (and the widget spec generally) were never a > good > > fit for the top-level-navigation case. Widgets, as far as I know, were > > always intended to be single page apps, and the tag wouldn't > have > > any affect on that at all. > > > > We've used it for nav in the past, though, so the question is whether > > familiarity with the old syntax trumps the fact that we're changing the > > behaviour. > > > > On Wed Dec 17 2014 at 11:47:02 AM Chuck Lantz > > wrote: > > > > > I suppose that is a good question. I took a look at the Widget Access > > > Request Policy W3C spec where that element comes from. It's actually > > > pretty ambiguous. > > > > > > "A user agent enforces an access request policy. ... In the default > > > policy, a user agent must deny access to network resources external to > > > the widget by default, whether this access is requested through APIs > > (e.g. > > > XMLHttpRequest) or through markup (e.g. iframe, script, img).." > > > > > > ... but... > > > > > > "A user agent may apply a different default policy if the widget is > > > being used in a context that defines its own policy, such as for > > > instance a widget served over HTTP. A more lenient policy can be > > > defined with the access-request list as defined in the processing > > > section. ... Furthermore, a user agent may grant access to certain URI > > > schemes (e.g., mailto:) without the need of an access request if its > > > security policy considers those schemes benign." > > > > > > It strikes me that today we implement the default policy and what > > > we're proposing here is a more lenient, alternate policy. > > > > > > For what it's worth, here's how this is defined in the Windows world: > > > > > > > > > https://www.google.com"; Type="include" /> > > > > > > > > > -Chuck > > > > > > -Original Message- > > > From: Ian Clelland [mailto:iclell...@chromium.org] > > > Sent: Wednesday, December 17, 2014 8:16 AM > > > To: dev@cordova.apache.org > > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > > > Definitely want to handle iOS, with the same policy. I've been working > > > on that in parallel with Android. > > > > > > Do we want to use for Nav? I wasn't sure, given its history, > > > and the fact that we're changing its behaviour. Is it better to stick > > > with the familiar tag and change what it tries to do? Or create a new > > > tag and deprecate ? > > > > > > On Wed Dec 17 2014 at 10:30:18 AM Chuck Lantz > > > wrote: > > > > > > > What about top level nav and script access? Would the thought be > > > > that the elements would map to that in the base platform? > > > > I'm thinking in terms of consistency across the different platforms. > > > > It strikes me we'd want to update iOS at least as well. > > > > > > > > -Chuck > > > > > > > > -Original Message- > > > > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of > > > > Andrew Grieve > > > > Sent: Tuesday, December 16, 2014 7:21 AM > > > > To: dev > > > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > > > > > On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz > > > wrote: > > > > > > > > > > Near term, for Windows 8.0/8.1, a custom security policy is in > > > > > place at the platform level for store apps so CSP doesn't really > > > > > apply there at the moment. (And, to be really specific, CSP > > > > > support is pretty limited in > > > > > IE10/11 focusing on the sandbox directive. The Windows 10 Tech > > > > > Preview is where you can see the real support in IE right now.) > > > > > So, it's a more of forward-thinking topic in that world. > > > > > > > > > > A related question, however - CSP support only started in the > > > > > Android browser with 4.4 did it not? Obviously Crosswalk would > > > > > have it but
[GitHub] cordova-cli pull request: added --list support
Github user jsoref commented on a diff in the pull request: https://github.com/apache/cordova-cli/pull/199#discussion_r22110323 --- Diff: doc/run.txt --- @@ -31,3 +31,4 @@ Experimental Flags --browserify ... Plugins javascript gets loaded at build time instead of runtime using browserify. Replaces cordovajs file with one that includes the JS of the installed plugins. +--list . Prints out available targets for Cordova - device and emulator. --- End diff -- This should have a way to list only device / only emulator. --- 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-cli pull request: added --list support
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-cli/pull/199#discussion_r22110362
--- Diff: src/cli.js ---
@@ -91,13 +90,13 @@ function cli(inputArgs) {
};
// If no inputArgs given, use process.argv.
-inputArgs = inputArgs || process.argv
--- End diff --
Please split fixes to code style from feature work -- i.e. they should be
distinct commits (you can put them together in the same pull request).
---
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-cli pull request: added --list support
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-cli/pull/199#discussion_r22110399
--- Diff: src/cli.js ---
@@ -288,4 +288,4 @@ function cli(inputArgs) {
};
cordova.raw[cmd](subcommand, targets, download_opts).done();
}
-}
+}
--- End diff --
You should not be removing the new line at end of file (i.e. if you see
this red null on a green background at the end, your patch/commit/file is bad,
open the file in your text editor, add a blank line at the end of the file, and
save it, then commit --amend...
---
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: How to handle CSP for XHR in Cordova 4.0
With that in mind, perhaps the thing to do here is to reuse access. Will the nav whitelist be in the base? That would indicate to me it should reuse access for upgrade situations. There's already the "launch-external" attribute that's non-standard so if we have to we could add another attribute. If we essentially say that CSP + nav whitelist is the recommended pattern, then the xhr whitelist becomes the exception. Do we expect that people will want to use both nav and XHR? I kind of think you'd use one or the other since XHR also blocks nav. That would mean that the element could be used in either situation and you simply see a different behavior with the XHR plugin installed. -Chuck -Original Message- From: Ian Clelland [mailto:iclell...@chromium.org] Sent: Friday, December 19, 2014 5:34 AM To: dev@cordova.apache.org Subject: Re: How to handle CSP for XHR in Cordova 4.0 On Thu Dec 18 2014 at 9:42:18 AM Andrew Grieve wrote: > That's a good point Chuck. Since the meaning of would be > changing in a dramatic way, I think we should just come up with > something new, and leave for anyone that wants to use the > legacy-whitelist plugin. > > Maybe: > PATTERN > PATTERN > > On Wed, Dec 17, 2014 at 5:29 PM, Chuck Lantz wrote: > > > > Yeah, I also am thinking about "upgrade" situations where someone > > takes > an > > existing app and moves it to Android Cordova 4.0. It strikes me > > there > we'd > > either want the existing behavior to be preserved (flaws aside) or > > move > it > > to the top level nav behavior. Did I read correctly the current > whitelist > > would be refactored out to a plugin? > And yes, the current whitelist, flaws and all, is refactored out into org.apache.cordova.legacy-whitelist. The source is in the cordova-plugins repo; it hasn't been published yet. Ian > > > > -Chuck > > > > -Original Message- > > From: Ian Clelland [mailto:iclell...@chromium.org] > > Sent: Wednesday, December 17, 2014 1:02 PM > > To: dev@cordova.apache.org > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > I think that access tags (and the widget spec generally) were never > > a > good > > fit for the top-level-navigation case. Widgets, as far as I know, > > were always intended to be single page apps, and the tag > > wouldn't > have > > any affect on that at all. > > > > We've used it for nav in the past, though, so the question is > > whether familiarity with the old syntax trumps the fact that we're > > changing the behaviour. > > > > On Wed Dec 17 2014 at 11:47:02 AM Chuck Lantz > > wrote: > > > > > I suppose that is a good question. I took a look at the Widget > > > Access Request Policy W3C spec where that element comes from. > > > It's actually pretty ambiguous. > > > > > > "A user agent enforces an access request policy. ... In the > > > default policy, a user agent must deny access to network resources > > > external to the widget by default, whether this access is > > > requested through APIs > > (e.g. > > > XMLHttpRequest) or through markup (e.g. iframe, script, img).." > > > > > > ... but... > > > > > > "A user agent may apply a different default policy if the widget > > > is being used in a context that defines its own policy, such as > > > for instance a widget served over HTTP. A more lenient policy can > > > be defined with the access-request list as defined in the > > > processing section. ... Furthermore, a user agent may grant access > > > to certain URI schemes (e.g., mailto:) without the need of an > > > access request if its security policy considers those schemes benign." > > > > > > It strikes me that today we implement the default policy and what > > > we're proposing here is a more lenient, alternate policy. > > > > > > For what it's worth, here's how this is defined in the Windows world: > > > > > > > > > https://www.google.com"; Type="include" /> > > > > > > > > > -Chuck > > > > > > -Original Message- > > > From: Ian Clelland [mailto:iclell...@chromium.org] > > > Sent: Wednesday, December 17, 2014 8:16 AM > > > To: dev@cordova.apache.org > > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > > > Definitely want to handle iOS, with the same policy. I've been > > > working on that in parallel with Android. > > > > > > Do we want to use for Nav? I wasn't sure, given its > > > history, and the fact that we're changing its behaviour. Is it > > > better to stick with the familiar tag and change what it tries to > > > do? Or create a new tag and deprecate ? > > > > > > On Wed Dec 17 2014 at 10:30:18 AM Chuck Lantz > > > > > > wrote: > > > > > > > What about top level nav and script access? Would the thought > > > > be that the elements would map to that in the base platform? > > > > I'm thinking in terms of consistency across the different platforms. > > > > It strikes me we'd want to update iOS at least as well. > > > > > > > > -Chuck > > > > > > > > -O
[GitHub] cordova-cli pull request: added --list support
Github user jsoref commented on the pull request: https://github.com/apache/cordova-cli/pull/199#issuecomment-67654548 There already is functionally for this: https://issues.apache.org/jira/browse/CB-2972 You really should reuse this instead of forcing each platform to reimplement this feature. If you want to use it as a fallback instead of a first preference, that's ok. But it isn't ok to make us do work again just to catch up when we've already implemented a feature. --- 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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request: https://github.com/apache/cordova-android/pull/139#discussion_r22110916 --- Diff: .travis.yml --- @@ -1,5 +1,4 @@ language: android install: npm install script: -- npm test -- npm run test-build \ No newline at end of file +- npm test --- End diff -- I know that this file already had a missing eol at eof (the red null on red background), when editing if you see this in the diff, please add the newline so that the green side doesn't show red null on green background. --- 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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-android/pull/139#discussion_r22110967
--- Diff: bin/lib/check_reqs.js ---
@@ -59,9 +59,13 @@ module.exports.get_target = function() {
return extractFromFile(path.join(ROOT, 'framework',
'project.properties'));
}
if (fs.existsSync(path.join(ROOT, 'project.properties'))) {
-// if no target found, we're probably in a project and
project.properties is in ROOT.
+// we can be in a project and project.properties can be in ROOT.
return extractFromFile(path.join(ROOT, 'project.properties'));
}
+if (fs.existsSync(path.join(ROOT, '..', '..', 'framework',
'project.properties'))) {
+// if not found, we can be testing.
+return extractFromFile(path.join(ROOT, '..', '..', 'framework',
'project.properties'));
+}
--- End diff --
I don't see how this relates to the feature work you're doing, it should
probably be a distinct commit and probably have a distinct CB-number in
http://issues.apache.org/
---
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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request: https://github.com/apache/cordova-android/pull/139#discussion_r22110985 --- Diff: bin/templates/cordova/lib/run.js --- @@ -19,6 +19,10 @@ under the License. */ +/* jshint node:true, bitwise:true, undef:true, trailing:true, quotmark:true, + indent:4, unused:vars, latedef:nofunc +*/ --- End diff -- This should definitely not be in the same commit as the feature work you're doing. --- 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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-android/pull/139#discussion_r22111025
--- Diff: bin/templates/cordova/lib/run.js ---
@@ -49,12 +54,45 @@ var path = require('path'),
install_target = '--emulator';
} else if (args[i].substring(0, 9) == '--target=') {
install_target = args[i].substring(9, args[i].length);
+} else if (args[i] == '--list') {
+list = true;
} else {
console.error('ERROR : Run option \'' + args[i] + '\' not
recognized.');
process.exit(2);
}
}
+function displayDevices() {
--- End diff --
If you're going to add this, there really should be a JSON output format
available.
---
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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-android/pull/139#discussion_r22111059
--- Diff: bin/templates/cordova/lib/run.js ---
@@ -49,12 +54,45 @@ var path = require('path'),
install_target = '--emulator';
} else if (args[i].substring(0, 9) == '--target=') {
install_target = args[i].substring(9, args[i].length);
+} else if (args[i] == '--list') {
+list = true;
} else {
console.error('ERROR : Run option \'' + args[i] + '\' not
recognized.');
process.exit(2);
}
}
+function displayDevices() {
--- End diff --
And there should be a way to specify whether a client wants to know about
defined but unavailable devices.
---
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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-android/pull/139#discussion_r2227
--- Diff: bin/templates/cordova/lib/run.js ---
@@ -129,4 +167,4 @@ module.exports.help = function(args) {
console.log('--emulator : Will deploy the built project to an
emulator if one exists');
console.log('--target= : Installs to the target with
the specified id.');
process.exit(0);
-}
+};
--- End diff --
I'm not quite sure why this line has a tan background instead of green, but
again, you shouldn't be removing the eol from eof (and thus having a red null
appear on the tan background).
---
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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-android/pull/139#discussion_r2253
--- Diff: package.json ---
@@ -13,8 +13,7 @@
"apache"
],
"scripts": {
-"test": "jasmine-node --color spec",
-"test-build": "rm -rf \"test create\"; ./bin/create \"test
create\" com.test.app å¿ç¨ && \"./test create/cordova/build\" && rm -rf
\"test create\""
--- End diff --
Why did you remove `test-build`?
---
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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-android/pull/139#discussion_r2269
--- Diff: package.json ---
@@ -23,7 +22,6 @@
"shelljs": "^0.2.6"
},
"devDependencies": {
-"jasmine-node": "~1",
-"promise-matchers": "~0"
--- End diff --
Why are you removing `promise-matchers`?
---
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-cli pull request: added --list support
Github user jsoref commented on the pull request: https://github.com/apache/cordova-cli/pull/199#issuecomment-67654989 Lastly, you need to include a JIRA number in each commit, please read: http://wiki.apache.org/cordova/IssueWorkflow (And if there are bugs in the workflow, please let us know, we're happy to fix any ambiguities...) If each of your pull requests for this feature shared a CB- number, then it'd be a lot easier for me to get from here to apache/cordova-android#139 or apache/cordova-ios#122 --- 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-android pull request: --list support for android
Github user jsoref commented on a diff in the pull request: https://github.com/apache/cordova-android/pull/139#discussion_r2297 --- Diff: spec/create.spec.js --- @@ -1,82 +0,0 @@ -/** --- End diff -- moving files from `spec/` to `test/spec` should be in a distinct commit from any feature work. --- 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-ios pull request: --list feature for iOS
Github user jsoref commented on a diff in the pull request: https://github.com/apache/cordova-ios/pull/122#discussion_r22111402 --- Diff: bin/templates/scripts/cordova/run --- @@ -40,6 +40,11 @@ USE_SIMULATOR=false # options --- End diff -- it'd be really nice if run was converted to node.js before this work... (again, that should be a distinct commit w/ a distinct bug number -- there might already be a bug number for 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-ios pull request: --list feature for iOS
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-ios/pull/122#discussion_r22111443
--- Diff: tests/spec/cordovalib.spec.js ---
@@ -36,7 +36,7 @@ describe('cordova-lib', function() {
return_code = shell.exec(command).code;
// if iOS Simulator is running, kill it
-if (return_code == 0) { // found
+if (return_code === 0) { // found
--- End diff --
again, cleanup like this should be in a distinct commit...
---
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-ios pull request: --list feature for iOS
Github user jsoref commented on a diff in the pull request:
https://github.com/apache/cordova-ios/pull/122#discussion_r22111477
--- Diff: tests/spec/create.spec.js ---
@@ -103,4 +103,15 @@ describe('create', function() {
shell.rm('-rf', tmp);
});
+});
+
+describe('end-to-end list validation', function(){
+it('handles list parameter', function() {
+shell.cp('-f', path.join(cordova_bin, 'check_reqs'),
path.join(cordova_bin, 'templates', 'scripts', 'cordova', 'check_reqs'));
+var command = '"' + path.join(cordova_bin, 'templates', 'scripts',
'cordova', 'run') + '" --list';
+var output = shell.exec(command, {silent: true}).output;
+expect(output).toMatch(/Available iOS Virtual Devices/);
+expect(output).toMatch(/Available iOS Devices/);
+shell.rm('-f', path.join(cordova_bin, 'templates', 'scripts',
'cordova', 'check_reqs'));
+});
});
--- End diff --
and again, when you see a red null on white background, please fix it by
adding the newline to the end of the file.
---
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
iOS 8.2 beta 3 out
iOS 8.2 beta 3 is out. I have ran the mobilespec tests and did not find any issues. Just FYI Thanks, Edna
RE: --list argument for CLI
Murat wrote: > I've the initial work available as pull requests here: > cordova-cli: https://github.com/apache/cordova-cli/pull/199 > cordova-android: https://github.com/apache/cordova-android/pull/139 > cordova-ios: https://github.com/apache/cordova-ios/pull/122 > If anyone has time to go through the pull requests and accept, that would be > fantastic! Hi murat, Sorry for not getting around to them sooner. They were on my list of things I am interested in. A colleague asked me about something related, so I just spent the time to give feedback. Before you take the time to read my feedback, I'd like to get you to think back to how you started working on Cordova. Which web pages / documentation did you find/read? What did they take you to? Where there sections that you skipped because "I already know how to do X"? Then, read through the wiki page I mentioned in the feedback. If that wiki page wasn't one of the ones you already read, then please indicate what you read. Because we need to ensure that contributors do see it. Also, if any of the things I've mentioned aren't listed in the pages that you will have read, please let us know so that we can fix them :). If you skipped a section, and it turns out that the section has relevant content, please let us know, in one case, a section's name hinted to someone that it was standard stuff when in fact it had other important Cordova specific details, so we tried to rename the link (I don't know if it worked, you're perhaps the first person who can tell me...). Thanks, and welcome.
[GitHub] cordova-plugin-file-transfer pull request: CB-6503 allow file uplo...
Github user ianjosephwilson commented on the pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/27#issuecomment-67674326 I just needed this for the Amazon S3 rest upload. Did something like this PR already get integrated? --- 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
FYI: git client vulnerability announced
Just affects clients. Consider updating your git client. https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
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-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 > * 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 > >
Re: [Vote] 4.0.0 Ubuntu Release
We need you to add your gpg key to dist/keys. Checkout the publish to dist/keys step at https://github.com/apache/cordova-coho/blob/master/docs/setting-up-gpg.md#creating-a-pgp-key-for-releases Once this is done, I can verify the archive was made by you and give the +1 Sorry for all the hoops (the apache way) -Steve On Thu, Dec 18, 2014 at 6:34 AM, Maxim Ermilov wrote: > > Please review and vote on this 4.0.0 Ubuntu Release. > > Release issue: https://issues.apache.org/jira/browse/CB-8173 > > Repos ready to be released have been published to dist/dev: > https://dist.apache.org/repos/dist/dev/cordova/CB-8173 > > The package was published from its corresponding git tag: > cordova-ubuntu: 4.0.0 (193fe98aba) > > 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-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 > * Performed manual tests to ensure platform could be successfully built and > run > > -Maxim >
Reason for node_modules in Platform Repos
Hi all, What was the design decision and reasoning behind full node_module directories being committed to platform repositories along with the source, instead of being installed from the respective package.json at the time that the platform is obtained? Kindly, Dmitry Blotsky
Re: Reason for node_modules in Platform Repos
none. go fix it! On Fri, Dec 19, 2014 at 12:07 PM, Dmitry Blotsky wrote: > Hi all, > > What was the design decision and reasoning behind full node_module > directories being committed to platform repositories along with the source, > instead of being installed from the respective package.json at the time > that the platform is obtained? > > Kindly, > > Dmitry Blotsky >
Re: Reason for node_modules in Platform Repos
Not true! It was for stability so that we wouldn't be reliant on various things that could fail/change/flake. Personally, in our network environment, any project which decides to reference a git: url becomes unimportable. If they happen to be transcluded via packaged node_modules, then this is a non-issue. On 12/19/14, 3:16 PM, "Brian LeRoux" wrote: >none. go fix it! > >On Fri, Dec 19, 2014 at 12:07 PM, Dmitry Blotsky >wrote: > >> Hi all, >> >> What was the design decision and reasoning behind full node_module >> directories being committed to platform repositories along with the >>source, >> instead of being installed from the respective package.json at the time >> that the platform is obtained? smime.p7s Description: S/MIME cryptographic signature
Re: Reason for node_modules in Platform Repos
yeh, we've been through this in other threads. pin the dep in package.json to a version or sha and your problem is solved. the only time a node_modules should be checked in, maybe, is in a deployment scenario for hosted service type things. (bad corp networks aside!) On Fri, Dec 19, 2014 at 12:18 PM, Josh Soref wrote: > Not true! > > It was for stability so that we wouldn't be reliant on various things that > could fail/change/flake. > > Personally, in our network environment, any project which decides to > reference a git: url becomes unimportable. > > If they happen to be transcluded via packaged node_modules, then this is a > non-issue. > > On 12/19/14, 3:16 PM, "Brian LeRoux" wrote: > > >none. go fix it! > > > >On Fri, Dec 19, 2014 at 12:07 PM, Dmitry Blotsky > >wrote: > > > >> Hi all, > >> > >> What was the design decision and reasoning behind full node_module > >> directories being committed to platform repositories along with the > >>source, > >> instead of being installed from the respective package.json at the time > >> that the platform is obtained? >
Re: Reason for node_modules in Platform Repos
Brian LeRoux wrote: >yeh, we've been through this in other threads. pin the dep in >package.json to a version or sha and your problem is solved. the only time >a node_modules should be checked in, maybe, is in a deployment scenario >for >hosted service type things. > >(bad corp networks aside!) Bad corporate networks exist. And they block ssh: (I.e. git:). It's really painful to have things fail just because someone decided to use git://github.com instead of https://github.com … I'm also pretty sure that we don't currently have the right code to actually get dependencies and install them when we do a platform add. So while you may want to make a hand waving statement about "we should stop doing this", someone would almost certainly have to write code to make it do the right thing. Further, that doesn't fix the case I've described above. I don't see a reason to change the status quo, and I have identified a reason not to change it. smime.p7s Description: S/MIME cryptographic signature
RE: --list argument for CLI
Hi Josh, Amazing feedback, thank you for spending the time going through all the changes! I've read the wiki page you mentioned before but looks like I've missed the section of it regarding commit messages, my bad. I have a question about decoupling of feature work and other tasks (such as code style issues and refactoring). Should other tasks also be tagged with the original feature CB tag? Or should I just treat them as a separate item with a separate CB tag and make a new pull request for it? Thanks, Murat -Original Message- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Friday, December 19, 2014 8:08 AM To: dev@cordova.apache.org Subject: RE: --list argument for CLI Murat wrote: > I've the initial work available as pull requests here: > cordova-cli: https://github.com/apache/cordova-cli/pull/199 > cordova-android: https://github.com/apache/cordova-android/pull/139 > cordova-ios: https://github.com/apache/cordova-ios/pull/122 > If anyone has time to go through the pull requests and accept, that would be > fantastic! Hi murat, Sorry for not getting around to them sooner. They were on my list of things I am interested in. A colleague asked me about something related, so I just spent the time to give feedback. Before you take the time to read my feedback, I'd like to get you to think back to how you started working on Cordova. Which web pages / documentation did you find/read? What did they take you to? Where there sections that you skipped because "I already know how to do X"? Then, read through the wiki page I mentioned in the feedback. If that wiki page wasn't one of the ones you already read, then please indicate what you read. Because we need to ensure that contributors do see it. Also, if any of the things I've mentioned aren't listed in the pages that you will have read, please let us know so that we can fix them :). If you skipped a section, and it turns out that the section has relevant content, please let us know, in one case, a section's name hinted to someone that it was standard stuff when in fact it had other important Cordova specific details, so we tried to rename the link (I don't know if it worked, you're perhaps the first person who can tell me...). Thanks, and welcome. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Reason for node_modules in Platform Repos
Josh, you are really abrasive and need to work on that. The corp network thing isn't a reason for anyone except RIM and Adobe IT departments and even then its not a real reason. If we architect for bad IT departments we may as well go full Apache Way and have singular SVN repo with <50% uptime and a 10 year release cycle. These are not hand waving statements. Using a package.json for deps is a well documented and understood practice. Someone *should* write some code and this would be a great first patch for a new developer looking to get their feet wet with the project. On Fri, Dec 19, 2014 at 12:48 PM, Josh Soref wrote: > Brian LeRoux wrote: > >yeh, we've been through this in other threads. pin the dep in > >package.json to a version or sha and your problem is solved. the only time > >a node_modules should be checked in, maybe, is in a deployment scenario > >for > >hosted service type things. > > > >(bad corp networks aside!) > > Bad corporate networks exist. And they block ssh: (I.e. git:). > > It's really painful to have things fail just because someone decided to > use git://github.com instead of https://github.com … > > > > I'm also pretty sure that we don't currently have the right code to > actually get dependencies and install them when we do a platform add. So > while you may want to make a hand waving statement about "we should stop > doing this", someone would almost certainly have to write code to make it > do the right thing. > > Further, that doesn't fix the case I've described above. > > I don't see a reason to change the status quo, and I have identified a > reason not to change it. >
Re: Reason for node_modules in Platform Repos
This. +1 -- tommy-carlos williams On 20 December 2014 at 08:05:53, Brian LeRoux (b...@brian.io) wrote: yeh, we've been through this in other threads. pin the dep in package.json to a version or sha and your problem is solved. the only time a node_modules should be checked in, maybe, is in a deployment scenario for hosted service type things.
[GitHub] cordova-plugin-camera pull request: CB-7938 - Create XCUnit unit t...
GitHub user shazron opened a pull request: https://github.com/apache/cordova-plugin-camera/pull/60 CB-7938 - Create XCUnit unit tests for iOS Camera plugin (squash the commits) You can merge this pull request into a Git repository by running: $ git pull https://github.com/shazron/cordova-plugin-camera CB-7938 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-camera/pull/60.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 #60 commit dc2d7c580115df3ec2e5911924022b51e5e314ca Author: Shazron Abdullah Date: 2014-11-05T20:19:42Z CB-7937 - Re-factor iOS Camera plugin so that it is testable commit 23c52fd49dfc91db7f89f88ab6073580434c Author: Shazron Abdullah Date: 2014-12-16T21:45:01Z CB-7938 - Added XCTest unit tests project, with stubs (adapted from SplashScreen unit test setup) commit 3ba27f79ccefaf1e225ce9d2e844419f412534b7 Author: Shazron Abdullah Date: 2014-12-17T21:44:06Z Fixed linker error with Obj-C Categories not loading commit afb79f69247be87ec96d404dba766a0826664e27 Author: Shazron Abdullah Date: 2014-12-17T21:45:30Z After fixing linker errors, got first unit test to work. commit 17790f6f954641f5694006e80f573107dc20a238 Author: Shazron Abdullah Date: 2014-12-19T18:18:06Z Completed tests for CDVCameraPicker and CDVPictureOptions. commit 0c9de232aaa9a8d1967979559e983800cc35a5ce Author: Shazron Abdullah Date: 2014-12-19T21:15:56Z Added tests for image scaling, cropping and correcting orientation. commit 85f94a2772670437ad3625eb5b7a96a963095dbd Author: Shazron Abdullah Date: 2014-12-19T21:23:23Z Fixed tests on command line failing (but passes in Xcode) --- 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: Reason for node_modules in Platform Repos
Hey folks, Thanks for the feedback! I agree with Josh, that requiring active dependency resolution introduces an extra point of failure. Even if a corporate network is fast and reliable, it has been explained to me that it is possible for a third-party dependency provider to pull their package from NPM, thus breaking a platform install. Keeping the dependency code inside the platform repo makes the code more robust. That does seem like a valid reason to do things the way we are doing them. Perhaps though, it should be mentioned in the documentation that that is how package repositories handle dependencies. I created a JIRA issue for this: https://issues.apache.org/jira/browse/CB-8195. As for getting feet wet, I am currently getting up to speed with the effort to get Cordova Medic on Apache Infrastructure, as per this JIRA ticket: https://issues.apache.org/jira/browse/INFRA-8588. Kindly, Dmitry -Original Message- From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Friday, December 19, 2014 1:04 PM To: dev@cordova.apache.org Subject: Re: Reason for node_modules in Platform Repos Josh, you are really abrasive and need to work on that. The corp network thing isn't a reason for anyone except RIM and Adobe IT departments and even then its not a real reason. If we architect for bad IT departments we may as well go full Apache Way and have singular SVN repo with <50% uptime and a 10 year release cycle. These are not hand waving statements. Using a package.json for deps is a well documented and understood practice. Someone *should* write some code and this would be a great first patch for a new developer looking to get their feet wet with the project. On Fri, Dec 19, 2014 at 12:48 PM, Josh Soref wrote: > Brian LeRoux wrote: > >yeh, we've been through this in other threads. pin the dep in > >package.json to a version or sha and your problem is solved. the only > >time a node_modules should be checked in, maybe, is in a deployment > >scenario for hosted service type things. > > > >(bad corp networks aside!) > > Bad corporate networks exist. And they block ssh: (I.e. git:). > > It's really painful to have things fail just because someone decided > to use git://github.com instead of https://github.com … > > > > I'm also pretty sure that we don't currently have the right code to > actually get dependencies and install them when we do a platform add. > So while you may want to make a hand waving statement about "we should > stop doing this", someone would almost certainly have to write code to > make it do the right thing. > > Further, that doesn't fix the case I've described above. > > I don't see a reason to change the status quo, and I have identified a > reason not to change it. >
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-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 > * 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
