[GitHub] cordova-plugman pull request: CB-7143 OSX platform cannot be insta...
GitHub user tripodsan opened a pull request: https://github.com/apache/cordova-plugman/pull/86 CB-7143 OSX platform cannot be installed as described - add OS X to list of known platforms You can merge this pull request into a Git repository by running: $ git pull https://github.com/tripodsan/cordova-plugman CB-7143 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugman/pull/86.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 #86 commit 19cb5f3fd1f6eee7546cc87ae8ec0898b88f408b Author: Tobias Bocanegra tri...@adobe.com Date: 2015-08-22T05:13:27Z CB-7143 OSX platform cannot be installed as described - add OS X to list of known platforms --- 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: Integrated new search css and added sor...
Github user dblotsky commented on the pull request: https://github.com/apache/cordova-docs/pull/309#issuecomment-133628503 Merged, but forgot to add the comment, sorry! Feel free to delete the branch. --- 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
Buildbot: buildslave cordova-osx-slave was lost
The Buildbot working for 'ASF Buildbot' has noticed that the buildslave named cordova-osx-slave went away It last disconnected at Fri Aug 21 12:26:42 2015 (buildmaster-local time) The admin on record (as reported by BUILDSLAVE:info/admin) was 'Dmitry Blotsky dblot...@microsoft.com '. Sincerely, The Buildbot http://ci.apache.org/ http://ci.apache.org/buildslaves/cordova-osx-slave - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [cordova-lib] Tests require cordova-android devDependencies being updated?
Cordova-lib tests does use Android platform for e2e test purposes, but it is not required to be installed - it's being cloned and used by the tests themselves. I've just tried to repro this on clean Windows 8 installation: - Installed latest git - Installed latest node.js - git clone https://github.com/apache/cordova-lib - cd cordova-lib\cordova-lib - npm install - npm test It worked just fine for me, all tests have passed. Also, these tests are being ran on each commit on AppVeyor and TravisCI: https://ci.appveyor.com/project/Humbedooh/cordova-lib https://travis-ci.org/apache/cordova-lib I don't see the issue there too. It looks like environment issue to me. Thanks, Alexander Sorokin -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Thursday, August 20, 2015 9:59 PM To: dev@cordova.apache.org Subject: [cordova-lib] Tests require cordova-android devDependencies being updated? Firstly I updated all my repos by running: coho repo-update -r all Then, I tried to run npm test on cordova-lib on master and I got some failures: -- Failures: 1) (save flag) platform add --save spec.1 should support custom tgz files Message: timeout: timed out after 6 msec waiting for spec to complete 2) (save flag) platform add --save spec.7 should save git url with git ref properly Message: Expected false to be true. 3) (save flag) platform update --save spec.11 should update spec with git url when updating using git url -- Not sure what was going on. I nuked `node_modules` and ran `npm install` again in `cordova-lib`, I still get the same failures. At Steve Gill's prompting, I updated the `cordova-android` repo by running `npm install` in the sibling directory, then ran `npm test` again for cordova-lib, and this time all the tests pass. Based on this evidence, I think cordova-lib has a dependency on cordova-android somehow? If so, why should it? (which means downloading the cordova-lib repo and running tests won't work). Note that I did not have Android installed on my computer either. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
File.spec.144 purpose
Hi guys. It looks like file.spec.144 copyTo: asset directory tries to copy whole www directory. Was it done intentionally? On slow environments, especially emulators this can take huge amount of time (up to 5 minutes). In case it is not substantial and any folder will do, I've prepared a fix for this test to stop timing out on Android emulators: https://github.com/apache/cordova-plugin-file/pull/129 Thanks, Alexander Sorokin
[GitHub] cordova-lib pull request: Adds implementation for PlatformApiPoly ...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-lib/pull/282 Adds implementation for PlatformApiPoly class according to PlatformApi spec This implements PlatformApiPoly class according to PlatformApi spec, which allows to: * create/update platform * execute platform's actions (build/run/add/update) * do a prepare (needed for CLI workflow only) * install/uninstall plugins Other noticeable changes: * removes `getPlatformProject` and PlatformProject method/class in favor of PlatformApiPoly/getPlatformApi * make assets and js-modules installing/uninstalling through ActionStack * refactor configChanges to not require plugins_dir in constructor * moves mergeXml helper to xml-helpers This should be used along with cordova-cli/platformApi branch You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-lib PlatformApi Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-lib/pull/282.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 #282 commit c93124c045a4a816fdcb5921e6e58dd667b60c95 Author: Vladimir Kotikov v-vlk...@microsoft.com Date: 2015-07-10T12:37:54Z Initial Implementation of PlatformApiPoly This implements PlatformApiPoly class according to PlatformApi spec, which allows to: * create/update platform * execute platform's actions (build/run/add/update) * do a prepare (needed for CLI workflow only) * install/uninstall plugins Other noticeable changes: * removes `getPlatformProject` and PlatformProject method/class in favor of PlatformApiPoly/getPlatformApi * make assets and js-modules installing/uninstalling through ActionStack * refactor configChanges to not require plugins_dir in constructor * moves mergeXml helper to xml-helpers This should be used along with cordova-cli/platformApi branch --- 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-ubuntu pull request: Success callback id and error callbac...
Github user jtrosby closed the pull request at: https://github.com/apache/cordova-ubuntu/pull/13 --- 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 refactoring implementation
Hi, guys. I've submitted a PR, that refactors a cordova-lib API and implements a PlatformApi polyfill as discussed in https://github.com/cordova/cordova-discuss/pull/12 Brief overview of this PR:
[GitHub] cordova-cli pull request: Updates cli to pass arguments properly t...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-cli/pull/220 Updates cli to pass arguments properly to PlatformApi instances You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-cli platformApi Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-cli/pull/220.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 #220 commit 96a2f3c607679cce8bb72fa18e2ac6b79e7e05aa Author: Vladimir Kotikov v-vlk...@microsoft.com Date: 2015-07-10T13:10:12Z Updates cli to pass structured args to platform methods --- 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
CB-9523 Show out of date message for older cordova CLI
Hi guys, I wanted to discuss the PR [1], which is adding update notification to CLI - will this be a useful addition? PR uses update-notifier[2] module, which notifies about Cordova update available daily - should I set this interval to something else like 1 week? [1] https://github.com/apache/cordova-cli/pull/219 [2] https://github.com/yeoman/update-notifier Please let me know if you have any questions or considerations. Best regards, Sergey Shakhnazarov
RE: Cordova-lib refactoring implementation
Oops, previous email sent by mistake ☹ Hi, guys. I’ve submitted a PR, that refactors a cordova-lib API and implements a PlatformApi polyfill (as discussed in https://github.com/cordova/cordova-discuss/pull/12) Please find it here: https://github.com/apache/cordova-lib/pull/282. To test this you'll also need to check out corresponding PR to cordova-cli: https://github.com/apache/cordova-cli/pull/220. This is a first step of refactoring, which includes cordova-lib refactoring only. The next steps once this PR will be reviewed and merged: * Move shared code for platforms/cordova-lib into cordova-common module * Prepare and publish cordova-common (this also includes coho update) * Switch cordova-lib to use cordova-common Brief overview of this PR: It implements PlatformApiPoly class according to PlatformApi spec, which allows to: * create/update platform * execute platform's actions (build/run/add/update) * do a prepare (needed for CLI workflow only) * install/uninstall plugins Other noticeable changes: * removes `getPlatformProject` and PlatformProject method/class in favor of PlatformApiPoly/getPlatformApi * make assets and js-modules installing/uninstalling through ActionStack * refactor configChanges to not require plugins_dir in constructor * moves mergeXml helper to xml-helpers I would appreciate any feedback on this PR. Best regards, Vladimir.
[GitHub] cordova-plugin-file pull request: Fixed bug with installation
Github user Nilos commented on the pull request: https://github.com/apache/cordova-plugin-file/pull/110#issuecomment-133565181 Your version of cordova-cli is outdated please run a npm update -g cordova You might need to run sudo npm update -g cordova to allow npm update access to restricted files. --- 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: File.spec.144 purpose
Can we add some of this info to a comment in the code, or put a link to this thread? There are far too many tests where it is not easy to glean what we are actually testing. My team is hiring! @purplecabbage risingj.com On Fri, Aug 21, 2015 at 11:45 AM, Suraj Pindoria suraj.pindo...@yahoo.com.invalid wrote: LGTM. On Friday, August 21, 2015 10:48 AM, Suraj Pindoria suraj.pindo...@yahoo.com.INVALID wrote: Was just replying when Ian responded. The reason I changed the test was because the plugin folders do not not exist when using browserify. I am running mobilespec now to see if everything is still good with your new changes. Suraj. On Friday, August 21, 2015 10:34 AM, Ian Clelland iclell...@chromium.org wrote: Yes and no -- it looks like a deliberate change, but it wasn't the original intention of the test -- the test was put in place as part of https://issues.apache.org/jira/browse/CB-6428, and it originally tested that it could copy just the file plugin's assets into local storage. CB-6428 is about being able to read from android_assets, and so any directory within the app assets would do. I suspect that the file plugin's dir was chosen because it should exist if we're testing it. The source directory was changed, though, about two weeks ago, with this commit: https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c (no JIRA issue, but the comments is that it fixes an issue when browserify is used -- I presume that the JS-concatenation means that the plugin JS files aren't present anymore.) So, any directory under /android_assets/ will do, but you should make sure that your patch doesn't fail in the same way as the original if browserify is being used. On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) v-als...@microsoft.com wrote: Hi guys. It looks like file.spec.144 copyTo: asset directory tries to copy whole www directory. Was it done intentionally? On slow environments, especially emulators this can take huge amount of time (up to 5 minutes). In case it is not substantial and any folder will do, I've prepared a fix for this test to stop timing out on Android emulators: https://github.com/apache/cordova-plugin-file/pull/129 Thanks, Alexander Sorokin
Re: [DISCUSS] CORDOVA AND LIVERELOAD
This is really cool work, and will absolutely help developers. Personally, I prefer the plugin approach. Which library is chosen is entirely up to the plugin author, but I really like BrowserSync! In all cases, I believe it is important to try NOT to add features to cordova. The ultimate goal is have cordova be intrinsic to all device platforms, and the more things we build into cordova, the more difficult this becomes. Others may have different views, and I am anxious to hear them, but that is the way I have always looked at it. My team is hiring! @purplecabbage risingj.com On Fri, Aug 21, 2015 at 11:50 AM, Mefire O. ommen...@microsoft.com wrote: Hi all, Problem Most Web developement workflows today have a quick edit-refresh-preview loop, enabling rapid application development. While Cordova is based on Web technologies, the cordova run step after every little HTML or CSS change is still slow and takes a considerable amount of time to deploy to the emulator or device. Some livereload-related offerings : https://scotch.io/tutorials/a-quick-guide-to-using-livereload-with-gulp . Adding the live reload capability in Cordova would increase developer efficiency. Note that varieties of LiveReload already in many downstream Cordova distributions. Prototypes Browsersynchttp://browsersync.io/ is a popular livereload library that enables refreshing the browser/webview when HTML/CSS/JS or images change, mirrors clicks and scrolls across multiple devices and even does incremental CSS or DOM updates. Here is a prototype implementation https://github.com/MSOpenTech/cordova-lib/commits/LiveReload that I put together into cordova-lib using BrowserSync and can be started easily using --livereload with the cordova run command : `cordova run android -livereload` An alternative approach here implements a similar functionality using a Cordova pluginhttps://github.com/axemclion/cordova-plugin-browsersync. Here is another plugin https://github.com/fingerproof/cordova-plugin-gapreload that implements livereload using LiveReloadhttp://livereload.com/ instead of browserSyc. Design Questions What would be the best approach to add this functionality into Cordova ? 1. In cordova-lib as prototyped above ? 2. As a Plugins with hooks that start browserSync? 3. As a plugin with hooks that uses LiveReload ? 4. A plugin that is a part of the default template 5. Any other suggestions Trying to list the goals from our implementation 1. Live reload should be discoverable, quick to get started and easy to use. It should be available to all developers in a standard way. 2. It should integrate well with existing workflows and not come in the way of existing solutions that already have live reload. 3. It should work for most major platforms. Note that the above examples change the content src= to a http:// server. This has a different behavior from the default Cordova app. 4. Though the above examples depend on browsersync, there are other equally good solutions like LiveReload, Amok, etc. Should we depend on BrowserSync? Or will using a plugin approach give us the flexibility of using alternate solutions Here's a link to the corresponding cordova-discuss proposal : https://github.com/omefire/cordova-discuss/commits/LiveReload Thanks, Mefire
Re: File.spec.144 purpose
LGTM. On Friday, August 21, 2015 10:48 AM, Suraj Pindoria suraj.pindo...@yahoo.com.INVALID wrote: Was just replying when Ian responded. The reason I changed the test was because the plugin folders do not not exist when using browserify. I am running mobilespec now to see if everything is still good with your new changes. Suraj. On Friday, August 21, 2015 10:34 AM, Ian Clelland iclell...@chromium.org wrote: Yes and no -- it looks like a deliberate change, but it wasn't the original intention of the test -- the test was put in place as part of https://issues.apache.org/jira/browse/CB-6428, and it originally tested that it could copy just the file plugin's assets into local storage. CB-6428 is about being able to read from android_assets, and so any directory within the app assets would do. I suspect that the file plugin's dir was chosen because it should exist if we're testing it. The source directory was changed, though, about two weeks ago, with this commit: https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c (no JIRA issue, but the comments is that it fixes an issue when browserify is used -- I presume that the JS-concatenation means that the plugin JS files aren't present anymore.) So, any directory under /android_assets/ will do, but you should make sure that your patch doesn't fail in the same way as the original if browserify is being used. On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) v-als...@microsoft.com wrote: Hi guys. It looks like file.spec.144 copyTo: asset directory tries to copy whole www directory. Was it done intentionally? On slow environments, especially emulators this can take huge amount of time (up to 5 minutes). In case it is not substantial and any folder will do, I've prepared a fix for this test to stop timing out on Android emulators: https://github.com/apache/cordova-plugin-file/pull/129 Thanks, Alexander Sorokin
Re: File.spec.144 purpose
Yes and no -- it looks like a deliberate change, but it wasn't the original intention of the test -- the test was put in place as part of https://issues.apache.org/jira/browse/CB-6428, and it originally tested that it could copy just the file plugin's assets into local storage. CB-6428 is about being able to read from android_assets, and so any directory within the app assets would do. I suspect that the file plugin's dir was chosen because it should exist if we're testing it. The source directory was changed, though, about two weeks ago, with this commit: https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c (no JIRA issue, but the comments is that it fixes an issue when browserify is used -- I presume that the JS-concatenation means that the plugin JS files aren't present anymore.) So, any directory under /android_assets/ will do, but you should make sure that your patch doesn't fail in the same way as the original if browserify is being used. On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) v-als...@microsoft.com wrote: Hi guys. It looks like file.spec.144 copyTo: asset directory tries to copy whole www directory. Was it done intentionally? On slow environments, especially emulators this can take huge amount of time (up to 5 minutes). In case it is not substantial and any folder will do, I've prepared a fix for this test to stop timing out on Android emulators: https://github.com/apache/cordova-plugin-file/pull/129 Thanks, Alexander Sorokin
Re: File.spec.144 purpose
Was just replying when Ian responded. The reason I changed the test was because the plugin folders do not not exist when using browserify. I am running mobilespec now to see if everything is still good with your new changes. Suraj. On Friday, August 21, 2015 10:34 AM, Ian Clelland iclell...@chromium.org wrote: Yes and no -- it looks like a deliberate change, but it wasn't the original intention of the test -- the test was put in place as part of https://issues.apache.org/jira/browse/CB-6428, and it originally tested that it could copy just the file plugin's assets into local storage. CB-6428 is about being able to read from android_assets, and so any directory within the app assets would do. I suspect that the file plugin's dir was chosen because it should exist if we're testing it. The source directory was changed, though, about two weeks ago, with this commit: https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c (no JIRA issue, but the comments is that it fixes an issue when browserify is used -- I presume that the JS-concatenation means that the plugin JS files aren't present anymore.) So, any directory under /android_assets/ will do, but you should make sure that your patch doesn't fail in the same way as the original if browserify is being used. On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) v-als...@microsoft.com wrote: Hi guys. It looks like file.spec.144 copyTo: asset directory tries to copy whole www directory. Was it done intentionally? On slow environments, especially emulators this can take huge amount of time (up to 5 minutes). In case it is not substantial and any folder will do, I've prepared a fix for this test to stop timing out on Android emulators: https://github.com/apache/cordova-plugin-file/pull/129 Thanks, Alexander Sorokin
[DISCUSS] CORDOVA AND LIVERELOAD
Hi all, Problem Most Web developement workflows today have a quick edit-refresh-preview loop, enabling rapid application development. While Cordova is based on Web technologies, the cordova run step after every little HTML or CSS change is still slow and takes a considerable amount of time to deploy to the emulator or device. Some livereload-related offerings : https://scotch.io/tutorials/a-quick-guide-to-using-livereload-with-gulp . Adding the live reload capability in Cordova would increase developer efficiency. Note that varieties of LiveReload already in many downstream Cordova distributions. Prototypes Browsersynchttp://browsersync.io/ is a popular livereload library that enables refreshing the browser/webview when HTML/CSS/JS or images change, mirrors clicks and scrolls across multiple devices and even does incremental CSS or DOM updates. Here is a prototype implementationhttps://github.com/MSOpenTech/cordova-lib/commits/LiveReload that I put together into cordova-lib using BrowserSync and can be started easily using --livereload with the cordova run command : `cordova run android -livereload` An alternative approach here implements a similar functionality using a Cordova pluginhttps://github.com/axemclion/cordova-plugin-browsersync. Here is another pluginhttps://github.com/fingerproof/cordova-plugin-gapreload that implements livereload using LiveReloadhttp://livereload.com/ instead of browserSyc. Design Questions What would be the best approach to add this functionality into Cordova ? 1. In cordova-lib as prototyped above ? 2. As a Plugins with hooks that start browserSync? 3. As a plugin with hooks that uses LiveReload ? 4. A plugin that is a part of the default template 5. Any other suggestions Trying to list the goals from our implementation 1. Live reload should be discoverable, quick to get started and easy to use. It should be available to all developers in a standard way. 2. It should integrate well with existing workflows and not come in the way of existing solutions that already have live reload. 3. It should work for most major platforms. Note that the above examples change the content src= to a http:// server. This has a different behavior from the default Cordova app. 4. Though the above examples depend on browsersync, there are other equally good solutions like LiveReload, Amok, etc. Should we depend on BrowserSync? Or will using a plugin approach give us the flexibility of using alternate solutions Here's a link to the corresponding cordova-discuss proposal : https://github.com/omefire/cordova-discuss/commits/LiveReload Thanks, Mefire
[VOTE] Windows 4.1.0 release
Please review and vote on this 4.1.0 Windows Release by replying to this email (and keep discussion on the DISCUSS thread) Release issue: https://issues.apache.org/jira/browse/CB-9447 The archive has been published to dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-9447 The package was published from its corresponding git tag: cordova-windows: 4.1.0 (05863b2fee) Note that you can test it out via: cordova platform add windows@https://dist.apache.org/repos/dist/dev/cordova/CB-9447/cordova-windows-4.1.0.tgz Blog post to review is here: https://github.com/MSOpenTech/apache-blog-posts/blob/CB-9447/2015-08-18-cordova-windows-4.1.0.md Upon a successful vote I will upload the archive to dist/, publish it to NPM, and post the 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 * Ensured continuous build was green when repo was tagged (except for the ones which were red due to sharing violation; they were green otherwise). - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Cordova Face to Face meeting
Update: I am working of getting the conferences rooms and other logistics set up for 2 days. We should most likely be able to do it on the 2 dates that we have proposed. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, August 20, 2015 6:07 PM To: dev@cordova.apache.org Subject: Re: Cordova Face to Face meeting Yes Monaca very good indeed, I saw their stuff at AngularU On Thu, Aug 20, 2015 at 9:02 PM Ryan J. Salva rsa...@microsoft.com wrote: I'm reaching out to the guys at Ionic and Telerik. Masa from Monaca has already indicated his desire to attend. rjs Ryan J. Salva | Principal Program Manager Lead Visual Studio Tools for Apache Cordova rsa...@microsoft.com 425 706 5270 office 206 612 5079 mobile My team is hiring. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, August 20, 2015 6:00 PM To: dev@cordova.apache.org Subject: Re: Cordova Face to Face meeting It will be cool if folks that leverage cordova attend to hear what they have to say and position on move the web/mobile community forward, folks like Ionic, Telerik, React-Native, NPM any others? Can you guys have contacts to reach out, I can ping Ionic Slack to see if they are aware of the Meetup Oh still working on travel approval, now the financial overloads want expense budget What should I enter the $ field for the fax? :-) On Wed, Aug 19, 2015 at 6:49 PM Carlos Santana csantan...@gmail.com wrote: I don't have travel approval yet, they wanted the specific date first - Carlos Sent from my iPhone On Aug 19, 2015, at 2:21 PM, Victor Sosa sosah.vic...@gmail.com wrote: As Julio says, please share the notes, recordings or comments you guys agree (I envy all the attendees so much, especially Carlos :P) On Wed, Aug 19, 2015 at 12:46 PM Parashuram N panar...@microsoft.com wrote: Awesome, I will get started on the logistics side to book 14 as the pivot, and see if I can do 13 or 15. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, August 19, 2015 9:50 AM To: dev@cordova.apache.org Subject: Re: Cordova Face to Face meeting I have closed the doodle. Oct, wed 14th has the best availability. Everyone who responded can make it. I suggest we pick that day and combine it with either the 13th or the 15th to make this a two day meeting. Let us know if that works for booking space at Microsoft Parashuram! If so, the rest of us can start booking flights. On Tue, Aug 18, 2015 at 10:18 PM, Parashuram N panar...@microsoft.com wrote: Can we close this doodle now? Also, just to be clear, we are not explicitly limiting this to committers - anyone interested in the development of the project is welcome. However, I am guessing that we will not be talking basics of Cordova, so this may not be a meeting to learn about Cordova or how to use it. -Original Message- From: tommy-carlos williams [mailto:to...@devgeeks.org] Sent: Monday, August 17, 2015 1:58 PM To: dev@cordova.apache.org Subject: Re: Cordova Face to Face meeting FOMO! :( Enjoy… On 18 August 2015 at 06:57:27, julio cesar sanchez (jcesarmob...@gmail.com) wrote: I can't go, too far, too expensive and not much vacation left. Take notes and share them with the ones that can't go. Have fun! El lunes, 17 de agosto de 2015, Jesse purplecabb...@gmail.com escribió: Done. On Aug 17, 2015, at 10:29 AM, Steven Gill stevengil...@gmail.com javascript:; wrote: Last chance to enter availability in doodle for the face to face. Doodle: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f% 2f do od le.com%2f58peh49rqm2tbyhm.data=01%7c01%7cpanarasi%40microsoft .c om %7 ca44398aab81048792cbd08d2a746a93e%7c72f988bf86f141af91ab2d7cd0 11 db 47 %7c1sdata=bpF1gRGmcSv55a2awYz0AHBjxt47Hz0TaR%2fLXAHZNg0%3d I am closing it tomorrow so we can try to finalize the dates and book flights. On Fri, Aug 7, 2015 at 4:08 PM, Carlos Santana csantan...@gmail.com javascript:; wrote: I think 2 days is a good idea it will give a chance to have a social night #jsdrinking I think I'm the last person to suggest since I'm wrestling with the fax machine here :-) On Fri, Aug 7, 2015 at 6:14 PM Carlos Santana csantan...@gmail.com javascript:; wrote: Yeah I would preferred more than a day. It would be hard to justify the business trip from North Carolina for a single day We are looking into sending two folks. - Carlos Sent from my iPhone On Aug 7, 2015, at 5:51 PM, Steven Gill stevengil...@gmail.com javascript:; wrote: I'd be open to 2 days but 1 could work to.
Re: [cordova-lib] Tests require cordova-android devDependencies being updated?
Definitely did happen to me on OS X and another dev had some weirdness as well. I'll try to see if I can replicate on a clean system -- perhaps there it's just some weird dev npm link issue on my end or something. On Friday, August 21, 2015, Alexander Sorokin (Akvelon) v-als...@microsoft.com wrote: Cordova-lib tests does use Android platform for e2e test purposes, but it is not required to be installed - it's being cloned and used by the tests themselves. I've just tried to repro this on clean Windows 8 installation: - Installed latest git - Installed latest node.js - git clone https://github.com/apache/cordova-lib - cd cordova-lib\cordova-lib - npm install - npm test It worked just fine for me, all tests have passed. Also, these tests are being ran on each commit on AppVeyor and TravisCI: https://ci.appveyor.com/project/Humbedooh/cordova-lib https://travis-ci.org/apache/cordova-lib I don't see the issue there too. It looks like environment issue to me. Thanks, Alexander Sorokin -Original Message- From: Shazron [mailto:shaz...@gmail.com javascript:;] Sent: Thursday, August 20, 2015 9:59 PM To: dev@cordova.apache.org javascript:; Subject: [cordova-lib] Tests require cordova-android devDependencies being updated? Firstly I updated all my repos by running: coho repo-update -r all Then, I tried to run npm test on cordova-lib on master and I got some failures: -- Failures: 1) (save flag) platform add --save spec.1 should support custom tgz files Message: timeout: timed out after 6 msec waiting for spec to complete 2) (save flag) platform add --save spec.7 should save git url with git ref properly Message: Expected false to be true. 3) (save flag) platform update --save spec.11 should update spec with git url when updating using git url -- Not sure what was going on. I nuked `node_modules` and ran `npm install` again in `cordova-lib`, I still get the same failures. At Steve Gill's prompting, I updated the `cordova-android` repo by running `npm install` in the sibling directory, then ran `npm test` again for cordova-lib, and this time all the tests pass. Based on this evidence, I think cordova-lib has a dependency on cordova-android somehow? If so, why should it? (which means downloading the cordova-lib repo and running tests won't work). Note that I did not have Android installed on my computer either. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org javascript:; For additional commands, e-mail: dev-h...@cordova.apache.org javascript:;
Re: Android Marshmallow Permissions
I realized I goofed and that accessing the camera wasn't actually a permission itself. It was permission for the camera to access your location. So everything should be working fine for older sdk + M preview. The issue about not returning to the app that calls the camera after accepting this permission is still a bug. On Fri, Aug 21, 2015 at 1:14 AM, Joe Bowser bows...@gmail.com wrote: On Thu, Aug 20, 2015 at 9:28 PM Karen Tran ktop...@gmail.com wrote: Hi all, I've been doing some testing with Android M Preview 3 and with Android API 23 to investigate the behavior I'm seeing with permissions. I tested older sdk levels with M Preview 3, API 23 with Preview 3, and API 23 with Lollipop. * If anyone has different results, let me know. On master, the target sdk level is currently set to 22. Running mobilespec at this target level on the 3rd Preview, all the automatic plugin tests passes. For manual tests, there are also no regressions, however, when testing the camera, I get prompted for permission. This seems odd, since we're using intents to do camera, so it may be camera asking for the camera permission? It's listed in the Android Best Practices now, which is hilarious, since we get so much hostility for using intents instead of owning our own camera. This is a bit odd because older sdk running on the Preview should use the old permission model, which is granting permission at install time, not runtime as stated in the Android documentation. Unless Camera is using the new permission model, because it's the new app. That said, the default Android Camera should already have permission. I think that this will literally be a one time thing. Another odd behavior is if I accept this permission for mobilespec, I never have to accept again, even if another app is accessing the camera. That sounds like the intent for camera asking for the permission, not MobileSpec. I tested this with another cordova app I made that calls the camera plugin. The last odd behavior I noticed is when you accept for camera, the camera app itself opens, so when you take a picture, you don't return to mobilespec. You just stay in the camera app. This only happens right after accepting. When you go back to mobilespec manually and use the camera again, the expected behavior of the camera resumes and your picture shows up in the yellow box of mobilespec. That is interesting, there's probably a bug with using intents this way, and a native Android Test app should be written to demonstrate this behaviour. This is very low priority, since most people will use the camera before using any other application. The above behaviors also happen with older sdk levels. Now manually setting the target sdk level to 23, all permissions are off by default, I don't get prompted for any permissions either when trying to run manual plugin tests. Of course having no permissions on, certain plugin tests will fail. Turning them all on manually, everything passes. Documentation of the new permission model says that we'll need to add some code to check for permissions and request them. That's currently as expected. We are currently working on code to ask for permissions, and we should be re-writing the plugins to expect the code to *On your apps that target the M Preview release or higher, make sure to check for and request permissions at runtime. To determine if your app has been granted a permission, call the newcheckSelfPermission() method. To request a permission, call the new requestPermissions() method. Even if your app is not targeting the M Preview release, you should test your app under the new permissions model.* The cordova permissions we'll need to handle are : - contacts - location - microphone - phone - storage Actually, plugin authors need to be able to handle all the permissions and ask for them. I have no idea what a third party plugin is going to need to access stuff, but I do know that it's bigger than the list here. Some may want some access to the phone itself, and to make calls. Those are the permissions our plugins need to ask for. Lastly testing Lollipop and older with API 23 looks fine. *TL;DR * Using M Preview with API 22 and older should be using the old permission model. All tests are passing except some strange behavior with the manual camera test which prompts for permission at runtime. Using M Preview with API 23 should use the new permission model where apps should request permission at runtime. Our cordova plugins will need to be updated to handle this. Using Lollipop and older with API 23 should use the old permission model. I didn't see any problems here. If you turn a permission off manually, there's problems and we should have code that addresses those problems. Since we target the lowest API, we will by default always have our
[GitHub] cordova-docs pull request: Integrated new search css and added sor...
GitHub user riknoll opened a pull request: https://github.com/apache/cordova-docs/pull/309 Integrated new search css and added sort for search results Added in the sort dropdown for plugin search results and integrated the new CSS You can merge this pull request into a Git repository by running: $ git pull https://github.com/riknoll/cordova-docs cordova-website Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-docs/pull/309.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 #309 commit d9a3ce8f023a9c16db96286d171f4934637301ae Author: riknoll rikn...@microsoft.com Date: 2015-08-22T00:53:02Z Integrated new search css and added sort --- 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-osx pull request: replace __PROJECT_NAME__ also in config....
GitHub user tripodsan opened a pull request: https://github.com/apache/cordova-osx/pull/15 replace __PROJECT_NAME__ also in config.xml and controller strings You can merge this pull request into a Git repository by running: $ git pull https://github.com/tripodsan/cordova-osx minor_changes Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-osx/pull/15.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 #15 commit 80aa6eca3164da81c51eaeee46c3bbf531ac53ad Author: Tobias Bocanegra tri...@adobe.com Date: 2015-08-21T23:37:30Z @trivial replace __PROJECT_NAME__ also in config.xml and controller strings --- 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] Windows 4.1.0 release
+1 Verified archive created and ran an app, ran device tests My team is hiring! @purplecabbage risingj.com On Fri, Aug 21, 2015 at 3:46 PM, Rob Paveza rob.pav...@microsoft.com wrote: Please review and vote on this 4.1.0 Windows Release by replying to this email (and keep discussion on the DISCUSS thread) Release issue: https://issues.apache.org/jira/browse/CB-9447 The archive has been published to dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-9447 The package was published from its corresponding git tag: cordova-windows: 4.1.0 (05863b2fee) Note that you can test it out via: cordova platform add windows@ https://dist.apache.org/repos/dist/dev/cordova/CB-9447/cordova-windows-4.1.0.tgz Blog post to review is here: https://github.com/MSOpenTech/apache-blog-posts/blob/CB-9447/2015-08-18-cordova-windows-4.1.0.md Upon a successful vote I will upload the archive to dist/, publish it to NPM, and post the 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 * Ensured continuous build was green when repo was tagged (except for the ones which were red due to sharing violation; they were green otherwise). - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Android Marshmallow Permissions
Filed a JIRA I think is low severity, maybe might have a clue to workaround. But like Joe said is very low probability that the first app to run on your new Android M is going to be a cordova app :-) before using the camera app. On Fri, Aug 21, 2015 at 7:54 PM Karen Tran ktop...@gmail.com wrote: I realized I goofed and that accessing the camera wasn't actually a permission itself. It was permission for the camera to access your location. So everything should be working fine for older sdk + M preview. The issue about not returning to the app that calls the camera after accepting this permission is still a bug. On Fri, Aug 21, 2015 at 1:14 AM, Joe Bowser bows...@gmail.com wrote: On Thu, Aug 20, 2015 at 9:28 PM Karen Tran ktop...@gmail.com wrote: Hi all, I've been doing some testing with Android M Preview 3 and with Android API 23 to investigate the behavior I'm seeing with permissions. I tested older sdk levels with M Preview 3, API 23 with Preview 3, and API 23 with Lollipop. * If anyone has different results, let me know. On master, the target sdk level is currently set to 22. Running mobilespec at this target level on the 3rd Preview, all the automatic plugin tests passes. For manual tests, there are also no regressions, however, when testing the camera, I get prompted for permission. This seems odd, since we're using intents to do camera, so it may be camera asking for the camera permission? It's listed in the Android Best Practices now, which is hilarious, since we get so much hostility for using intents instead of owning our own camera. This is a bit odd because older sdk running on the Preview should use the old permission model, which is granting permission at install time, not runtime as stated in the Android documentation. Unless Camera is using the new permission model, because it's the new app. That said, the default Android Camera should already have permission. I think that this will literally be a one time thing. Another odd behavior is if I accept this permission for mobilespec, I never have to accept again, even if another app is accessing the camera. That sounds like the intent for camera asking for the permission, not MobileSpec. I tested this with another cordova app I made that calls the camera plugin. The last odd behavior I noticed is when you accept for camera, the camera app itself opens, so when you take a picture, you don't return to mobilespec. You just stay in the camera app. This only happens right after accepting. When you go back to mobilespec manually and use the camera again, the expected behavior of the camera resumes and your picture shows up in the yellow box of mobilespec. That is interesting, there's probably a bug with using intents this way, and a native Android Test app should be written to demonstrate this behaviour. This is very low priority, since most people will use the camera before using any other application. The above behaviors also happen with older sdk levels. Now manually setting the target sdk level to 23, all permissions are off by default, I don't get prompted for any permissions either when trying to run manual plugin tests. Of course having no permissions on, certain plugin tests will fail. Turning them all on manually, everything passes. Documentation of the new permission model says that we'll need to add some code to check for permissions and request them. That's currently as expected. We are currently working on code to ask for permissions, and we should be re-writing the plugins to expect the code to *On your apps that target the M Preview release or higher, make sure to check for and request permissions at runtime. To determine if your app has been granted a permission, call the newcheckSelfPermission() method. To request a permission, call the new requestPermissions() method. Even if your app is not targeting the M Preview release, you should test your app under the new permissions model.* The cordova permissions we'll need to handle are : - contacts - location - microphone - phone - storage Actually, plugin authors need to be able to handle all the permissions and ask for them. I have no idea what a third party plugin is going to need to access stuff, but I do know that it's bigger than the list here. Some may want some access to the phone itself, and to make calls. Those are the permissions our plugins need to ask for. Lastly testing Lollipop and older with API 23 looks fine. *TL;DR * Using M Preview with API 22 and older should be using the old permission model. All tests are passing except some strange behavior with the manual camera test which prompts for permission at runtime. Using M Preview with API 23 should use
Re: [cordova-lib] Tests require cordova-android devDependencies being updated?
Shaz give it a good shake to your Mac :-) On Fri, Aug 21, 2015 at 5:58 PM Shazron shaz...@gmail.com wrote: Definitely did happen to me on OS X and another dev had some weirdness as well. I'll try to see if I can replicate on a clean system -- perhaps there it's just some weird dev npm link issue on my end or something. On Friday, August 21, 2015, Alexander Sorokin (Akvelon) v-als...@microsoft.com wrote: Cordova-lib tests does use Android platform for e2e test purposes, but it is not required to be installed - it's being cloned and used by the tests themselves. I've just tried to repro this on clean Windows 8 installation: - Installed latest git - Installed latest node.js - git clone https://github.com/apache/cordova-lib - cd cordova-lib\cordova-lib - npm install - npm test It worked just fine for me, all tests have passed. Also, these tests are being ran on each commit on AppVeyor and TravisCI: https://ci.appveyor.com/project/Humbedooh/cordova-lib https://travis-ci.org/apache/cordova-lib I don't see the issue there too. It looks like environment issue to me. Thanks, Alexander Sorokin -Original Message- From: Shazron [mailto:shaz...@gmail.com javascript:;] Sent: Thursday, August 20, 2015 9:59 PM To: dev@cordova.apache.org javascript:; Subject: [cordova-lib] Tests require cordova-android devDependencies being updated? Firstly I updated all my repos by running: coho repo-update -r all Then, I tried to run npm test on cordova-lib on master and I got some failures: -- Failures: 1) (save flag) platform add --save spec.1 should support custom tgz files Message: timeout: timed out after 6 msec waiting for spec to complete 2) (save flag) platform add --save spec.7 should save git url with git ref properly Message: Expected false to be true. 3) (save flag) platform update --save spec.11 should update spec with git url when updating using git url -- Not sure what was going on. I nuked `node_modules` and ran `npm install` again in `cordova-lib`, I still get the same failures. At Steve Gill's prompting, I updated the `cordova-android` repo by running `npm install` in the sibling directory, then ran `npm test` again for cordova-lib, and this time all the tests pass. Based on this evidence, I think cordova-lib has a dependency on cordova-android somehow? If so, why should it? (which means downloading the cordova-lib repo and running tests won't work). Note that I did not have Android installed on my computer either. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org javascript:; For additional commands, e-mail: dev-h...@cordova.apache.org javascript:;
Re: CB-9523 Show out of date message for older cordova CLI
_ / \ / ___ ___ \ / / |___| \ \ / / \ \ | | ^ ^ | | | | @ @ | | | |_| | |__ __| | | | | | | |___| |_| |___| Best I could do in 5 minutes. Happy Friday! My team is hiring! @purplecabbage risingj.com On Fri, Aug 21, 2015 at 5:30 PM, Carlos Santana csantan...@gmail.com wrote: +1 I like how yeoman and ionic cli has similar feature. But the PR can't go in unless you have a mean Cordova Icon printed in ASCII in the message :-) On Fri, Aug 21, 2015 at 12:44 PM Sergey Shakhnazarov (Akvelon) v-ses...@microsoft.com wrote: Hi guys, I wanted to discuss the PR [1], which is adding update notification to CLI - will this be a useful addition? PR uses update-notifier[2] module, which notifies about Cordova update available daily - should I set this interval to something else like 1 week? [1] https://github.com/apache/cordova-cli/pull/219 [2] https://github.com/yeoman/update-notifier Please let me know if you have any questions or considerations. Best regards, Sergey Shakhnazarov
[GitHub] cordova-osx pull request: CB-9541 Add preferences to put app into ...
GitHub user tripodsan opened a pull request: https://github.com/apache/cordova-osx/pull/16 CB-9541 Add preferences to put app into kiosk mode This adds the following new preferences: |name|comment|example| ||---|| |`WindowSize`|size of the application window in the format wxh. special values 'auto' and 'fullscreen' | `preference name=WindowSize value=fullscreen /`| |`HideMousePointer`|idle duration in seconds after which the mouse pointer should be hidden. '0' for always.| `preference name=HideMousePointer value=5/`| You can merge this pull request into a Git repository by running: $ git pull https://github.com/tripodsan/cordova-osx CB-9541 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-osx/pull/16.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 #16 commit fd38253bdfd7d6f1a25214ca4b2be571201c7565 Author: Tobias Bocanegra tri...@adobe.com Date: 2015-08-21T23:26:10Z CB-9541 Add preferences to put app into kiosk mode - adding WindowSize preference commit 61f89a78351d1daf6ab68f8a0fb4814d71a489be Author: Tobias Bocanegra tri...@adobe.com Date: 2015-08-22T00:12:11Z CB-9541 Add preferences to put app into kiosk mode - adding HideMousePointer preference --- 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: [DISCUSS] CORDOVA AND LIVERELOAD
This is so awesome, as working on a downstream I have being debating if this is something I should add to my downstream. I think this is standard stuff that cordova should enable but not include in core, it should be a plugin. maybe we should have a tag for plugins that are only for tooling, meaning that are easy to take out or ignore when building/running a production app. or be dormant until the --livereload is pass in the command line for emulate or run. I really think BrowserSync is rad, and having a plugin implemented by cordova is good as reference implementation if others want to implement a different one. but I think we can provide that satisfy the need of most developers. But I think the cordova-cli should document and have some convention support the developer to emulate/run with --livereload. then a plugin can declare that it provides the livereload feature, and detect that --livereload was pass do it's magic On Fri, Aug 21, 2015 at 5:14 PM Jesse purplecabb...@gmail.com wrote: This is really cool work, and will absolutely help developers. Personally, I prefer the plugin approach. Which library is chosen is entirely up to the plugin author, but I really like BrowserSync! In all cases, I believe it is important to try NOT to add features to cordova. The ultimate goal is have cordova be intrinsic to all device platforms, and the more things we build into cordova, the more difficult this becomes. Others may have different views, and I am anxious to hear them, but that is the way I have always looked at it. My team is hiring! @purplecabbage risingj.com On Fri, Aug 21, 2015 at 11:50 AM, Mefire O. ommen...@microsoft.com wrote: Hi all, Problem Most Web developement workflows today have a quick edit-refresh-preview loop, enabling rapid application development. While Cordova is based on Web technologies, the cordova run step after every little HTML or CSS change is still slow and takes a considerable amount of time to deploy to the emulator or device. Some livereload-related offerings : https://scotch.io/tutorials/a-quick-guide-to-using-livereload-with-gulp . Adding the live reload capability in Cordova would increase developer efficiency. Note that varieties of LiveReload already in many downstream Cordova distributions. Prototypes Browsersynchttp://browsersync.io/ is a popular livereload library that enables refreshing the browser/webview when HTML/CSS/JS or images change, mirrors clicks and scrolls across multiple devices and even does incremental CSS or DOM updates. Here is a prototype implementation https://github.com/MSOpenTech/cordova-lib/commits/LiveReload that I put together into cordova-lib using BrowserSync and can be started easily using --livereload with the cordova run command : `cordova run android -livereload` An alternative approach here implements a similar functionality using a Cordova pluginhttps://github.com/axemclion/cordova-plugin-browsersync. Here is another plugin https://github.com/fingerproof/cordova-plugin-gapreload that implements livereload using LiveReloadhttp://livereload.com/ instead of browserSyc. Design Questions What would be the best approach to add this functionality into Cordova ? 1. In cordova-lib as prototyped above ? 2. As a Plugins with hooks that start browserSync? 3. As a plugin with hooks that uses LiveReload ? 4. A plugin that is a part of the default template 5. Any other suggestions Trying to list the goals from our implementation 1. Live reload should be discoverable, quick to get started and easy to use. It should be available to all developers in a standard way. 2. It should integrate well with existing workflows and not come in the way of existing solutions that already have live reload. 3. It should work for most major platforms. Note that the above examples change the content src= to a http:// server. This has a different behavior from the default Cordova app. 4. Though the above examples depend on browsersync, there are other equally good solutions like LiveReload, Amok, etc. Should we depend on BrowserSync? Or will using a plugin approach give us the flexibility of using alternate solutions Here's a link to the corresponding cordova-discuss proposal : https://github.com/omefire/cordova-discuss/commits/LiveReload Thanks, Mefire
Re: CB-9523 Show out of date message for older cordova CLI
+1 I like how yeoman and ionic cli has similar feature. But the PR can't go in unless you have a mean Cordova Icon printed in ASCII in the message :-) On Fri, Aug 21, 2015 at 12:44 PM Sergey Shakhnazarov (Akvelon) v-ses...@microsoft.com wrote: Hi guys, I wanted to discuss the PR [1], which is adding update notification to CLI - will this be a useful addition? PR uses update-notifier[2] module, which notifies about Cordova update available daily - should I set this interval to something else like 1 week? [1] https://github.com/apache/cordova-cli/pull/219 [2] https://github.com/yeoman/update-notifier Please let me know if you have any questions or considerations. Best regards, Sergey Shakhnazarov
[GitHub] cordova-plugin-file pull request: CB-9539 Fixed test failure on An...
GitHub user alsorokin opened a pull request: https://github.com/apache/cordova-plugin-file/pull/129 CB-9539 Fixed test failure on Android emulator https://issues.apache.org/jira/browse/CB-9539 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-plugin-file CB-9539 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file/pull/129.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 #129 commit 632bd1ade76a16f67b72feb51751ebfb1af32e31 Author: alsorokin alexander.soro...@akvelon.com Date: 2015-08-21T09:18:38Z CB-9539 Fixed test failure on Android 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-plugin-file-transfer pull request: Add in default value fo...
GitHub user jason-ong opened a pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/98 Add in default value for fileName mimeType To match the FileUpload documentation for IOS , change fileName default value to image.jpg change mimeType default value to image/jpg You can merge this pull request into a Git repository by running: $ git pull https://github.com/jason-ong/cordova-plugin-file-transfer master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file-transfer/pull/98.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 #98 commit 4f7cdc28a8f68a4f3723b111bd797743ab1a788e Author: jason-ong jasonon...@gmail.com Date: 2015-08-21T09:35:42Z Add in default value for fileName mimeType To match the documentation for FileUpload, change fileName default value to image.jpg change mimeType default value to image/jpg --- 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
