[GitHub] cordova-android pull request: [CB-6898] Fix black screen issue whe...
GitHub user kurli opened a pull request: https://github.com/apache/cordova-android/pull/102 [CB-6898] Fix black screen issue when app start up Set appView invisible only when 'LoadingDialog' is enabled. BUG=https://issues.apache.org/jira/browse/CB-6898 You can merge this pull request into a Git repository by running: $ git pull https://github.com/kurli/cordova-android black-screen-issue Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-android/pull/102.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 #102 commit 14bdc259c3ebc3b48eeb26256047d4884ae4cf24 Author: guangzhen guangzhen...@intel.com Date: 2014-06-09T07:48:11Z [CB-6898] Fix black screen issue when app start up Set appView invisible only when 'LoadingDialog' is enabled. BUG=https://issues.apache.org/jira/browse/CB-6898 --- 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. ---
[GitHub] cordova-medic pull request: CB-6899 Cordova-lib link step fails ...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-medic/pull/9 CB-6899 Cordova-lib link step fails on Windows slave Replaces ln -s command, which is not workin on windows slaves, with inline node script. Fix for [CB-6899](https://issues.apache.org/jira/browse/CB-6899) You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-medic CB-6899 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-medic/pull/9.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 #9 commit 72fc3889b4dc50b2ada2095985a32e69703ed72e Author: Vladimir Kotikov v-vlk...@microsoft.com Date: 2014-06-09T08:57:42Z Replaces ln -s command, which is not workin on windows slaves, with inline node script. --- 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. ---
Tizen update
Hi, all! I've signed the ICLA and I've updated the PRs for the CLI and for plugman, so now they are against cordova-lib. https://github.com/apache/cordova-lib/pull/16 https://github.com/apache/cordova-lib/pull/17 Could someone please review them? TIA for your help, Gabriel
RE: [VOTE] Plugins Release
It seems that the tag points to a commit which is not present in any of the branches. I guess that the correct commit which should be tagged is: https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git;a=commit;h=992306bbc58f3ba9dc0f4dbcde1b084db5ba8169 -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Saturday, June 7, 2014 12:05 AM To: dev@cordova.apache.org Subject: Re: [VOTE] Plugins Release Marcel: Yes. Andrew: I see it https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git On Fri, Jun 6, 2014 at 9:02 AM, Andrew Grieve agri...@chromium.org wrote: I don't see the tag for inappbrowser. Forgot to push it? On Fri, Jun 6, 2014 at 10:46 AM, Marcel Kinard cmarc...@gmail.com wrote: Steve, to clarify, a single vote is for all the plugins listed below, correct? On Jun 5, 2014, at 5:44 PM, Steven Gill stevengil...@gmail.com wrote: Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-6877 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-6877/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (e6e911c941) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92) I am getting failing tests for contacts + battery. I have decided not to release them until they get reviewed. Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, 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 72 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ensured tests were passing on iOS Android by using createmobilespec script
[GitHub] cordova-plugin-device-motion pull request: CB-6888 Polish translat...
Github user zalun closed the pull request at: https://github.com/apache/cordova-plugin-device-motion/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. ---
[GitHub] cordova-medic pull request: CB-6889 Edit json step in master.cfg...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-medic/pull/10 CB-6889 Edit json step in master.cfg fails on Windows When running medic on windows (either the client and server or just a client), the Edit json step specified in master.cfg fails. *Reason:* Windows medic install uses the unix utilities from git\bin, the version of sed installed requires specification of backup suffix for -i option without space. ``` -i[SUFFIX], --in-place[=SUFFIX] edit files in place (makes backup if extension supplied) ``` from sed help. Fix for [CB-6889](https://issues.apache.org/jira/browse/CB-6889) You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-medic CB-6889 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-medic/pull/10.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 #10 commit 69a6ae92ced92c51cf12ec83b180a24308881bd0 Author: Vladimir Kotikov v-vlk...@microsoft.com Date: 2014-06-09T11:51:50Z Change -i sed's argument behaviour, which now works on both mac and windows. --- 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. ---
Re: [VOTE] Plugins Release
The code which is being voted on, though, isn't represented by that commit. There are significant differences. (They appear to be all confined to Firefox OS) The way to reproduce the original tagged commit is to cherry-pick commit 992306b (CB-6877 Updated version and RELEASENOTES.md for release 0.5.0) onto commit 393524a (CB-6127 Spanish and rench Translations added. Github close #23) Steve, can you push your commit e6e911c to the ASF repo, under some named branch? On Mon, Jun 9, 2014 at 7:16 AM, Martin Bektchiev martin.bektch...@telerik.com wrote: It seems that the tag points to a commit which is not present in any of the branches. I guess that the correct commit which should be tagged is: https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git;a=commit;h=992306bbc58f3ba9dc0f4dbcde1b084db5ba8169 -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Saturday, June 7, 2014 12:05 AM To: dev@cordova.apache.org Subject: Re: [VOTE] Plugins Release Marcel: Yes. Andrew: I see it https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git On Fri, Jun 6, 2014 at 9:02 AM, Andrew Grieve agri...@chromium.org wrote: I don't see the tag for inappbrowser. Forgot to push it? On Fri, Jun 6, 2014 at 10:46 AM, Marcel Kinard cmarc...@gmail.com wrote: Steve, to clarify, a single vote is for all the plugins listed below, correct? On Jun 5, 2014, at 5:44 PM, Steven Gill stevengil...@gmail.com wrote: Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-6877 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-6877/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (e6e911c941) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92) I am getting failing tests for contacts + battery. I have decided not to release them until they get reviewed. Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, 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 72 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ensured tests were passing on iOS Android by using createmobilespec script
Cordova and w3c spec Algnment - Vibration Gap Analysis
Cordova and w3c teams~ Last week Dom (from w3c) and myself met to chat about aligning the Cordova and w3c specs. We felt the best starting point was looking at the vibration spec as it shouldn't change... i.e. is pretty stable. I put together a Google Doc identifying the 4 areas that will need to be addresses and will create the corresponding JIRA issues for Cordova to track their process. Please take a look at the doc and feel free to edit or add comments (for those of you who tried earlier and couldn't access the doc, it is now open to anyone with the link): https://docs.google.com/document/d/18b32aveubsr2g5Co_VeW4q3s3IXxuddUU2BO5eC3jVA/edit This is the first step at getting Cordova and w3c better aligned. Dom and I plan on documenting the process so we can replicate the efforts across the other specs as well. Lisa Lisa Seacat DeLuca Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | ldel...@us.ibm.com | lisaseacat.com | |
Re: [VOTE] Plugins Release
I guess I'd have +1 the inappbrowser, although no idea if that counts as I'm the author of most fixes for ffo in this plugin Dnia Mon Jun 9 15:03:45 2014 Ian Clelland pisze: The code which is being voted on, though, isn't represented by that commit. There are significant differences. (They appear to be all confined to Firefox OS) The way to reproduce the original tagged commit is to cherry-pick commit 992306b (CB-6877 Updated version and RELEASENOTES.md for release 0.5.0) onto commit 393524a (CB-6127 Spanish and rench Translations added. Github close #23) Steve, can you push your commit e6e911c to the ASF repo, under some named branch? On Mon, Jun 9, 2014 at 7:16 AM, Martin Bektchiev martin.bektch...@telerik.com wrote: It seems that the tag points to a commit which is not present in any of the branches. I guess that the correct commit which should be tagged is: https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git;a=commit;h=992306bbc58f3ba9dc0f4dbcde1b084db5ba8169 -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Saturday, June 7, 2014 12:05 AM To: dev@cordova.apache.org Subject: Re: [VOTE] Plugins Release Marcel: Yes. Andrew: I see it https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git On Fri, Jun 6, 2014 at 9:02 AM, Andrew Grieve agri...@chromium.org wrote: I don't see the tag for inappbrowser. Forgot to push it? On Fri, Jun 6, 2014 at 10:46 AM, Marcel Kinard cmarc...@gmail.com wrote: Steve, to clarify, a single vote is for all the plugins listed below, correct? On Jun 5, 2014, at 5:44 PM, Steven Gill stevengil...@gmail.com wrote: Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-6877 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-6877/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (e6e911c941) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92) I am getting failing tests for contacts + battery. I have decided not to release them until they get reviewed. Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, 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 72 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ensured tests were passing on iOS Android by using createmobilespec script -- Piotr Zalewa Mozilla
Hangout
Assuming we will be doing the Hangout tomorrow, I created a draft agenda and notes placeholder as a Google Doc, and it is linked from the wiki: https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes Is the previously-scheduled time of 4pm EDT good? I think that maps to 8am for Tommy.
Re: Hangout
Sounds great, thanks for the agenda. Note, there are already some beefy items on the list and we always run short on time -- so before adding more please triple consider if items are important and cannot just be discussed on the lists. -Michal On Mon, Jun 9, 2014 at 10:55 AM, Marcel Kinard cmarc...@gmail.com wrote: Assuming we will be doing the Hangout tomorrow, I created a draft agenda and notes placeholder as a Google Doc, and it is linked from the wiki: https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes Is the previously-scheduled time of 4pm EDT good? I think that maps to 8am for Tommy.
Re: npm based cordova platform add
I'm sorry, I don't understand neither see the benefit or value added to this... What's the objective of this change? Are the node_modules platforms going to be usable by separately outside of Cordova in NodeJS? i.e. Can I use cordova-android to do an android app in NodeJS using the NPM module? What are the benefits of npm approach instead of the current library in $HOME/.cordova approach? Is there gonna be a breakage in the Cordova API? Many developer already complain about the huge changes introduced in service versions. Better to have a talk about this in tomorrow's hangout. 2014-06-03 11:03 GMT-05:00 Brian LeRoux b...@brian.io: package.json does all of this On Tue, Jun 3, 2014 at 8:55 AM, Andrew Grieve agri...@chromium.org wrote: On Tue, Jun 3, 2014 at 12:53 AM, purplecabbage purplecabb...@gmail.com wrote: $ cordova --usenpm platform add ios@3.4.1 Why would you do this? Because I want to use version 3.4.1 of cordova-ios. What version of cordova? I used cordova-cli @ master Do you expect to add multiple ios@versions to a single cordova project? No. Just want to be able to tell it what version of cordova-ios to use when adding or updating the platform. Ios@3.4.1 and android@3.5.2 Exactly. In order for platforms to ship separately, they must be versioned separately. Our version / dependency tree is already insane. Has anyone here submitted a cross device app to a store? Made anything more complicated than hello world? I feel like we're losing touch. Worrisome that you feel this way, but this is not actionable feedback. Sent from my iPhone On Jun 2, 2014, at 7:49 PM, Andrew Grieve agri...@chromium.org wrote: Tried it out. Seemed to work fine: $ cordova --usenpm platform update ios npm http GET https://registry.npmjs.org/cordova-ios/3.5.0 npm http 200 https://registry.npmjs.org/cordova-ios/3.5.0 npm http GET https://registry.npmjs.org/cordova-ios/-/cordova-ios-3.5.0.tgz npm http 200 https://registry.npmjs.org/cordova-ios/-/cordova-ios-3.5.0.tgz iOS project is now at version 3.5.0 $ ls ~/.cordova/lib/npm_cache/cordova-ios/3.5.0/ .cache.json package/ package.tgz $ cordova --usenpm platform update ios npm http GET https://registry.npmjs.org/cordova-ios/3.5.0 npm http 304 https://registry.npmjs.org/cordova-ios/3.5.0 iOS project is now at version 3.5.0 $ cordova --usenpm platform update ios@3.4.1 Platform ios@3.4.1 not recognized as a core cordova platform. See `cordova platform list`. $ cordova --usenpm platform add ios@3.4.1 Platform ios@3.4.1 not recognized as a core cordova platform. See `cordova platform list`. Thoughts for next steps: - Allow platform@version in the command-line (as I tried to do) - Delete url and version from platforms.js (WOOHOO!) - Add cordova cache ls and cordova cache clear commands - Advertise the new awsomeness! On Mon, Jun 2, 2014 at 5:46 PM, Brian LeRoux b...@brian.io wrote: but…why not package.json ? (leaving this discussion to the other thread) On Mon, Jun 2, 2014 at 3:28 PM, Mark Koudritsky kam...@google.com wrote: Hi All, I've added the bits needed to download platform files from npm when doing cordova platform add Currently this is hidden behind a --usenpm flag e.g: cordova --usenpm platform add ios Some testing would highly appreciated before we switch to npm as the default place to download the platform files from. The links changes in cordova-lib https://github.com/apache/cordova-lib/commit/55810360fe660276a1ab0d04382da633f9cf1290 and cordova-cli https://github.com/apache/cordova-cli/commit/57179d61d0c35e32c808198d184d0d515fbb0c28 Some of the platforms on npm: https://www.npmjs.org/package/cordova-android https://www.npmjs.org/package/cordova-ios https://www.npmjs.org/package/cordova-blackberry -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco
Re: Apache Cordova Translated using Microsoft Bing Translation...
Shane, I've communicated the limitations of what I expect to be approved to the internal MS team, but clearly it needs to be you that gives approval or otherwise. What I communicated internally (to MS) is that an appropriate use, such as the one you suggest, would likely be OK. I also suggested that a case study which explained how the translation was done would likely be OK (again paying attention to the appropriate policies). If you are OK with this as a basic principle, I'd be happy to help the internal team come up with the proposed materials and submit that to the Cordova PMC for their consideration and subsequent approval by yourself. Ross On 5 June 2014 13:37, Shane Curcuru a...@shanecurcuru.org wrote: (Note mixed public/private lists) It depends. What specific authorization is Microsoft looking for? As a public charity, we are happy to have respectful third parties like Microsoft use our product logos to refer to our products in a wide variety of places. We are even happy to have third parties build solutions atop our software, and then in some specific ways incorporate our product names into their product names (Powered By, etc.). Similarly, we're happy for third parties to describe how they use our products in various ways - we are far more liberal here and don't require explicit permissions for many of these things, which is very different from the average software vendor. But as a independent home for projects that often attract contributions from many different sources, we need to ensure that our brands are not used in ways that would serve to endorse a third party, or to promote any specific affiliation with third parties that would harm our projects' abilities to manage their governance independently of corporate influence, and to attract new contributors. We have strong draft guidelines for the flip side of this question, which merely need a bit more explanation before I update to best practices and push out - to give a flavor of the issues we should consider here: http://www.apache.org/foundation/marks/linking In general I would be fine with the translation team at Microsoft saying we've donated services to these open source projects: in a presentation or webpage where you list a variety of project names or logos. That's an appropriate factual reference, and makes the relationship clear. But I'm probably not fine with that team saying We're the best machine translators since Apache Cordova uses us! Does that help? If not, can you be more specific as to what uses of Apache brands you're looking for? My guess is that any uses you believe are respectful of the independent governance model that is a key part of the Apache brand would be fine - but it's difficult to say that without understanding the likely uses. Separately, Gianugo and Ross both are long time Apache Members who I know can provide the right kind of feedback to new ideas you might want to get a gut check on first. Also, if you do have feedback or additional questions, we'd appreciate them on trademarks@ so we can start to provide better up-front documentation about our expectations. It takes some time to write clear situations, but there are plenty of respectful uses of Apache brands that we want to promote, and don't need to require specific approvals of in each case. - Shane Curcuru VP, Brand Management The Apache Software Foundation On 6/5/14 8:00 AM, Lisa Seacat DeLuca wrote: Just following up on this. I haven't heard anyone from the Apache trademarks team chime in with this new updated request. Please let me know if there are any problems so I know whether I can move forward working with Microsoft on enhancing our translation efforts for Apache Cordova. Thanks, Lisa ... From: Ross Gardler rgard...@opendirective.com To: dev@cordova.apache.org dev@cordova.apache.org Cc: Lisa Seacat DeLuca/San Francisco/IBM@IBMUS, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com, Olivier Bloch (MS OPEN TECH) obl...@microsoft.com, Apache Brand Management tradema...@apache.org, Gianugo Rabellino (MS OPEN TECH) gianugo.rabell...@microsoft.com Date: 05/30/2014 08:19 PM Subject: Re: Apache Cordova Translated using Microsoft Bing Translation... ... Olivier, The ASF cannot grant open ended authorization for the trademarks. However, as long as a) the Cordova PMC are comfortable with the proposed use and b) it confirmed with the ASF trademark policy then there should be no problem with this. So, for example, approval to use the Cordova logo in case study should be fine. Reuse of the logo when presenting that case study should be fine (again, assuming conformance with the ASF trademark policy). On Fri, May 30, 2014 at 14:40 PM, Olivier Fontana olivi...@microsoft.com wrote: ... Hi Cordova team, In view of the limited volume requested we will waive the clause regarding the use of
[WP8][cordova-plugin-file] filesystem: null after use IsolatedStorageFile.MoveDirectory
I'm working on fix mobile spec automated tests, specifically on those which involves the File plugin. In the test # 67 of that test suite, I've found out that the problem is not that the directory is not moved, the problem is that after this line is executed: https://github.com/apache/cordova-plugin-file/blob/master/src/wp/File.cs#L1412 The DispatchCommandResult sends the entry file with the CallbackID, but the problem is that the information about the filesystem is missing. This situation it doesn't happen when isoFile.MoveFile(newPath), IsolatedStorageFile.CreateDirectory(path) or IsolatedStorageFile.CreateFile(path) are used the filesystem information it remains with those but not with MoveDirectory. During the 67 test and several others, it uses the filesystem information of the recent moved directory to determine if the file exists, and when it gets to GeFileOrDirectory on the options this is the array obtained: [null,file1,{\create\:false},File619232322] When Create or MoveFile: [\/\/entry,move.dsp.srcDir,file1,{\create\:false},File619232322] From the JS side object: MoveDirectory: {isFile:false, isDirectory:true, name : entry.move.dsp.dstDir, filesystem:null, nativeURL:null} MoveFile: {isFile:true, isDirectory:false, name : entry.move.dsp.dstDir, filesystem:FileSystem: persistent, nativeURL:null} That's the reason why some automated tests on the MoveTo section are failing. Tested on Windows Phone 8 and 8.1, emulator and device. Same behavior. Any thoughts about this? -- Regards, Martin Gonzalez
Re: [VOTE] Plugins Release
Hmmm. Definitely something wrong with inappbrowser tag. I just deleted it and retagged it. I will upload the new inappbrowser to dist/dev and start a new vote thread. I'm closing this thread. It has FAILED On Mon, Jun 9, 2014 at 7:53 AM, Piotr Zalewa pzal...@mozilla.com wrote: I guess I'd have +1 the inappbrowser, although no idea if that counts as I'm the author of most fixes for ffo in this plugin Dnia Mon Jun 9 15:03:45 2014 Ian Clelland pisze: The code which is being voted on, though, isn't represented by that commit. There are significant differences. (They appear to be all confined to Firefox OS) The way to reproduce the original tagged commit is to cherry-pick commit 992306b (CB-6877 Updated version and RELEASENOTES.md for release 0.5.0) onto commit 393524a (CB-6127 Spanish and rench Translations added. Github close #23) Steve, can you push your commit e6e911c to the ASF repo, under some named branch? On Mon, Jun 9, 2014 at 7:16 AM, Martin Bektchiev martin.bektch...@telerik.com wrote: It seems that the tag points to a commit which is not present in any of the branches. I guess that the correct commit which should be tagged is: https://git-wip-us.apache.org/repos/asf?p=cordova-plugin- inappbrowser.git;a=commit;h=992306bbc58f3ba9dc0f4dbcde1b084db5ba8169 -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Saturday, June 7, 2014 12:05 AM To: dev@cordova.apache.org Subject: Re: [VOTE] Plugins Release Marcel: Yes. Andrew: I see it https://git-wip-us.apache.org/repos/asf?p=cordova-plugin- inappbrowser.git On Fri, Jun 6, 2014 at 9:02 AM, Andrew Grieve agri...@chromium.org wrote: I don't see the tag for inappbrowser. Forgot to push it? On Fri, Jun 6, 2014 at 10:46 AM, Marcel Kinard cmarc...@gmail.com wrote: Steve, to clarify, a single vote is for all the plugins listed below, correct? On Jun 5, 2014, at 5:44 PM, Steven Gill stevengil...@gmail.com wrote: Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-6877 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-6877/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (e6e911c941) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92) I am getting failing tests for contacts + battery. I have decided not to release them until they get reviewed. Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, 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 72 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ensured tests were passing on iOS Android by using createmobilespec script -- Piotr Zalewa Mozilla
RE: Cordova and w3c spec Algnment - Vibration Gap Analysis
Here is some work that we have been doing - https://github.com/MSOpenTech/cordova-api-audit/compare/w3 As you can see from the diff, there were 2 approaches we took and would like feedback from folks here on the best approach to move forward with 1. Automated a. Picked up type definitions for Cordova plugins from definatelytyped.org b. Generated Typescript bindings from the W3C IDL for each of the spec c. Checked each into its own branch, can now do a git style diff, showing the exact differences - look at the contacts.d.ts file for the diffs in the contacts API. d. Since this is utomatic, can cover more ground quickly, we just need to tweak the output at the end - things like Object.getSetter, etc. We are working on those now. e. Given that this is hosted on github, this can be easily updated as we continue to change the API f.Can also facilitate inline discussions 2. Manual a. The Geolocation is a manual diff, all in Javascript. b. Still hosted on 2 github branches for enable automated diffs, inline discussions, etc. I think we can combine our efforts here and take an approach that works for all. Comments, suggestions? From: Lisa Seacat DeLuca [mailto:ldel...@us.ibm.com] Sent: Monday, June 9, 2014 7:20 AM To: Cordova Dev (dev@cordova.apache.org); public-device-a...@w3.org; Webapps WG Cc: Worklight Development Cordova Subject: Cordova and w3c spec Algnment - Vibration Gap Analysis Cordova and w3c teams~ Last week Dom (from w3c) and myself met to chat about aligning the Cordova and w3c specs. We felt the best starting point was looking at the vibration spec as it shouldn't change... i.e. is pretty stable. I put together a Google Doc identifying the 4 areas that will need to be addresses and will create the corresponding JIRA issues for Cordova to track their process. Please take a look at the doc and feel free to edit or add comments (for those of you who tried earlier and couldn't access the doc, it is now open to anyone with the link): https://docs.google.com/document/d/18b32aveubsr2g5Co_VeW4q3s3IXxuddUU2BO5eC3jVA/edit This is the first step at getting Cordova and w3c better aligned. Dom and I plan on documenting the process so we can replicate the efforts across the other specs as well. Lisa Lisa Seacat DeLuca Mobile Engineer | t: +415.787.4589 | ldel...@apache.orgmailto:ldel...@apache.org | | ldel...@us.ibm.commailto:ldel...@us.ibm.com | lisaseacat.comhttp://www.lisaseacat.com/ | [follow @LisaSeacat on twitter] www.twitter.com/LisaSeacat | [follow Lisa Seacat DeLuca on linkedin] http://www.linkedin.com/in/lisaseacat
[VOTE] Plugins Release (attempt 2)
Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-6877 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-6877/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (992306bbc5) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92) I am getting failing tests for contacts + battery. I have decided not to release them until they get reviewed. Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, 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 72 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ensured tests were passing on iOS Android by using createmobilespec script * Ran coho verify-tags with above output succssfully
Re: Tizen update
Hi Gabriel, we'll be reviewing and either closing or merging PRs there this week: thx! On Mon, Jun 9, 2014 at 3:46 AM, Schulhof, Gabriel gabriel.schul...@intel.com wrote: Hi, all! I've signed the ICLA and I've updated the PRs for the CLI and for plugman, so now they are against cordova-lib. https://github.com/apache/cordova-lib/pull/16 https://github.com/apache/cordova-lib/pull/17 Could someone please review them? TIA for your help, Gabriel
Re: wip on cordova-lib? pls let us know
where is that offending bit…and what is the intent behind it. outside of pretty stack traces I'm still not convinced of the utility of building out own own exceptions On Sat, Jun 7, 2014 at 6:19 AM, Andrew Grieve agri...@chromium.org wrote: Yep, I fully support this refactoring. Just wanted to encourage that you try the publish install flow earlier rather than later in case the instanceof thing does work. On Fri, Jun 6, 2014 at 3:42 PM, Michal Mocny mmo...@chromium.org wrote: Anis: sounds good. Thats was the original intent, and cordova-lib repo was the first step. Also agree that once we have a package that really is well decoupled from the rest, we can consider moving to independent repos, especially if it has some utility on its own. (The CordovaError point was just one issue we faced when we last contemplated how to do this, but we are less experienced here.) -Michal On Fri, Jun 6, 2014 at 3:25 PM, Lorin Beer lorin.b...@gmail.com wrote: Here's a wip for the breakout of the config parser module https://github.com/lorinbeer/cordova-lib/tree/configparser_module still need to tidy up the referencing but feedback welcome On Fri, Jun 6, 2014 at 11:03 AM, Anis KADRI anis.ka...@gmail.com wrote: The goal is to have independent modules that can be consumed. Andrew, your second example reflects what we want to achieve. Obviously, there will be more than CordovaError. Brian and I think that we can keep the current cordova-lib repository and create folders for each module (each with its own dependencies and package.json). Eventually, there could be more repositories if we chose to have them. Right now if you just want one piece of functionality from either plugman or cli you need the whole cordova-lib module which is extremely unfortunate and pretty silly. On Fri, Jun 6, 2014 at 10:55 AM, Michal Mocny mmo...@chromium.org wrote: Additionally, I think it will only be a problem when each of the modules call into one another. I.e. when cordova-cli calls into cordova-plugman and that throws a CordovaError which is caught by cordova-cli and then compared with instanceof to its own version.. Its not a problem in isolation. This problem usually comes up with singletons / internal caching, such as reading config files from disk once and then modifying in-memory, but I'm not sure if we actyally have that problem. -Michal On Fri, Jun 6, 2014 at 1:12 PM, Andrew Grieve agri...@chromium.org wrote: On Fri, Jun 6, 2014 at 12:37 PM, Brian LeRoux b...@brian.io wrote: Ya I spoke to Issac a bit about this last week and he wasn't being entirely facetious. One path that apparently works well is to treat root `./node_modules` as something npm manages and then nested node_modules for userspace stuff. eg. `./src/node_modules` and then `var foo = require('src/foo')` Not a huge win over just using relative paths so meh. I don't understand why instanceof wouldn't work? You probably have a better understanding of this than I do... But: - There's no problem when running locally, since we've defined the structure of node_modules to work, But when npm install is run on an end-users machine, if it ends up like: cordova-lib/node_modules/cordova-plugman/node_modules/CordovaError cordova-lib/node_modules/cordova-cli/node_modules/CordovaError cordova-lib/node_modules/CordovaError then there are now 3 CordovaError constructors, so instanceof will not work between them. Now, if npm sees that all packages call for the same version of CordovaError, and install them like: cordova-lib/node_modules/cordova-plugman cordova-lib/node_modules/cordova-cli cordova-lib/node_modules/CordovaError then all is well. Easy to answer with a quick test :) On Fri, Jun 6, 2014 at 9:14 AM, Andrew Grieve agri...@chromium.org wrote: Exciting! I tried the check in node_modules approach in cordova-app-harness and it works really well there: https://github.com/apache/cordova-app-harness/tree/master/harness-push It's a simpler case since there's a strict parent/child relationship. The main unknown for me is how to make CordovaError work as its own module since we'll require that there is never multiple copies of the module when the end-user types npm install (or else the instanceof check won't work). I *think* that npm does the right thing so long as all of the packages use the same version constraints for it, but I haven't tested it. On Fri, Jun 6, 2014 at 11:37
Re: Cordova strategy for Hosted Apps
Jesse does well answering the queries. Our ideal is to get cordova-browser somewhere production ready in the coming year. On Fri, Jun 6, 2014 at 1:24 PM, Jesse purplecabb...@gmail.com wrote: Hi Jeff, 1. Currently (out of the box) you can load the start page from the network or the device file system. However, you need to be aware of both CORS issues as well as App store policies which may make this approach un-submittable [1] . You can achieve this either by setting the content src=''/ in your config.xml file, or by redirecting from the index.html that is packaged with your app. The latter approach allows you to respond to no-network issues, which you must do in mobile anyway. cordova.js will need to live with your server pages, and any plugins, and cordova_plugins.js and all plugin files must match the versions of the native implementation that is compiled in the app. 2. Yes, it is a great way of testing, as you can skip the whole build, and just reload. If the app should function with/without the feature, then yes, it should detect it. 3. Similar to what you describe in #2, for targeting browsers generically. [1] 2.12 Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected. https://developer.apple.com/appstore/resources/approval/guidelines.html Cheers, Jesse @purplecabbage risingj.com On Fri, Jun 6, 2014 at 1:02 PM, Jeff Burtoft jeffb...@microsoft.com wrote: I have a tool that allows developers to take their web apps and build them into hosted store apps on Windows 8.1 and Windows Phone (8 and 8.1) called the Web App Templatehttps://wat.codeplex.com/. Some of the developers who are using the tool would like to see it go cross platform to Android and iOS, so that the same config file could be used to build hosted apps for the play store and App store just as it is on Windows. I love the idea of going cross platform, and when I think cross platform, I think Cordova, but after looking through some of the documentation, I'm not sure if it's a good fit. I'm looking for some direction on these questions: 1. Does Cordova have hosted apps (where the content lives on the server as opposed to being packaged with the app) in its roadmap? I realize you can do this today on most platforms with a redirect, but it seems to be more of a work around rather than a strategy. 2. Does it make sense to make Cordova device APIs available to hosted apps? In general these apps also must function in a browser , so the features would have to be implemented in a progressive enhancement model. 3. I see a build for Browser https://github.com/apache/cordova-browser on the Cordova website. What are the plans for this build? Can anyone help clarify some of this? Thanks, Jeff Burtoft HTML5 Evangelist \\ Web Technologies \\ Microsoft
Re: [VOTE] Plugins Release (attempt 2)
+1 - Verified that hashes match the tags. - Verified hashes sigs - Verified contents of plugin-camera (assuming others are fine) On Mon, Jun 9, 2014 at 1:48 PM, Steven Gill stevengil...@gmail.com wrote: Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-6877 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-6877/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (992306bbc5) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92) I am getting failing tests for contacts + battery. I have decided not to release them until they get reviewed. Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, 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 72 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ensured tests were passing on iOS Android by using createmobilespec script * Ran coho verify-tags with above output succssfully
minor bump to cordova-lib
Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: minor bump to cordova-lib
I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: [VOTE] Plugins Release (attempt 2)
+1 - Ran coho audit-license-headers, all looks good. - Ran coho verify-tags, all looks good. - Ran mobile-spec using Android Cordova platform 3.5.0 on Android 4.4.3. Ignoring the fails in Battery and Contacts, I see 2 other failing tests in Geolocation which I am tempted to ignore because this plugin is empty for Android since it falls back to the webview implementation for geolocation. On Jun 9, 2014, at 1:48 PM, Steven Gill stevengil...@gmail.com wrote: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (992306bbc5) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92)
[GitHub] cordova-blackberry pull request: CB-6850 use path.join() for black...
Github user jsoref closed the pull request at: https://github.com/apache/cordova-blackberry/pull/160 --- 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. ---
[GitHub] cordova-blackberry pull request: CB-6850 use path.join() for black...
Github user jsoref commented on the pull request: https://github.com/apache/cordova-blackberry/pull/160#issuecomment-45533957 merged --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cordova-blackberry pull request: CB-6757 Provide useful hint when ...
Github user jsoref closed the pull request at: https://github.com/apache/cordova-blackberry/pull/158 --- 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. ---
[GitHub] cordova-blackberry pull request: CB-6757 Provide useful hint when ...
Github user jsoref commented on the pull request: https://github.com/apache/cordova-blackberry/pull/158#issuecomment-45533991 merged --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cordova-blackberry pull request: CB-6398 Support additional comman...
Github user jsoref commented on the pull request: https://github.com/apache/cordova-blackberry/pull/153#issuecomment-45534097 this was merged --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: minor bump to cordova-lib
looking into the duplicate package.json issue thanks for catching the package.json issue, the duplicate is a mistaken inclusion the end goal is that configparser is it's own package, yes. Included the wrong package.json file On Mon, Jun 9, 2014 at 12:01 PM, Andrew Grieve agri...@chromium.org wrote: I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: minor bump to cordova-lib
In particular, I thought the root of the repo wasn't supposed to be a node package, but a bucket for multiple node packages. (ie, should not be a package.json at the root). We don't vote on commits (though its nice to ask for review for big hairy patches like this one, so thanks for that). -Michal On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve agri...@chromium.org wrote: I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: minor bump to cordova-lib
Michal: the root package.json is being removed. I do want to perform an npm publish with a patch version increment, so downstream projects can reference include by npm registry and not git url. That would constitute a 'release' of some sort. My understanding was that bug patches of this sort could be pushed out with minimum fuss. On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny mmo...@chromium.org wrote: In particular, I thought the root of the repo wasn't supposed to be a node package, but a bucket for multiple node packages. (ie, should not be a package.json at the root). We don't vote on commits (though its nice to ask for review for big hairy patches like this one, so thanks for that). -Michal On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve agri...@chromium.org wrote: I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: [VOTE] Plugins Release (attempt 2)
If you are interested in checking out the latest tag in each of the plugin repos, you can run the following command from the parent directory. This assumes all of the plugins are siblings. for l in cordova-plugin-*;do (cd $l; git checkout $(git describe --tags --abbrev=0)); done; To test the camera plugin, you can then do cordova plugin add ../cordova-plugin-camera (path depends on where your test project is in relation to plugin) Note: If you have uncommitted local changes in plugin repos, this won't work. You will have to either commit or stash them. I am going to see if I can publish these to our registry under the RC tag. So to test, you would be able to go cordova plugin add org.apache.cordova.camera@rc (similar to tools release) Hope this helps. On Mon, Jun 9, 2014 at 12:33 PM, Marcel Kinard cmarc...@gmail.com wrote: +1 - Ran coho audit-license-headers, all looks good. - Ran coho verify-tags, all looks good. - Ran mobile-spec using Android Cordova platform 3.5.0 on Android 4.4.3. Ignoring the fails in Battery and Contacts, I see 2 other failing tests in Geolocation which I am tempted to ignore because this plugin is empty for Android since it falls back to the webview implementation for geolocation. On Jun 9, 2014, at 1:48 PM, Steven Gill stevengil...@gmail.com wrote: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (992306bbc5) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92)
Re: minor bump to cordova-lib
We all wish! On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer lorin.b...@gmail.com wrote: Michal: the root package.json is being removed. I do want to perform an npm publish with a patch version increment, so downstream projects can reference include by npm registry and not git url. That would constitute a 'release' of some sort. My understanding was that bug patches of this sort could be pushed out with minimum fuss. On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny mmo...@chromium.org wrote: In particular, I thought the root of the repo wasn't supposed to be a node package, but a bucket for multiple node packages. (ie, should not be a package.json at the root). We don't vote on commits (though its nice to ask for review for big hairy patches like this one, so thanks for that). -Michal On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve agri...@chromium.org wrote: I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: Cordova strategy for Hosted Apps
To elaborate a bit more on #1, I’ve seen issues where the cordova.js in the hosted content gets out-of-sync with the native Cordova runtime installed on the device. Weird behavior can ensue when there are changes across Cordova versions in the js-native interactions. One brute-force way to deal with this would be to locally inspect the version of the native Cordova runtime, and ask the remote server to serve up the matching version of cordova.js. The folks writing hosted apps like this don’t see this design wrinkle until they are debugging weird behavior. On Jun 6, 2014, at 4:24 PM, Jesse purplecabb...@gmail.com wrote: Hi Jeff, 1. Currently (out of the box) you can load the start page from the network or the device file system. However, you need to be aware of both CORS issues as well as App store policies which may make this approach un-submittable [1] . You can achieve this either by setting the content src=''/ in your config.xml file, or by redirecting from the index.html that is packaged with your app. The latter approach allows you to respond to no-network issues, which you must do in mobile anyway. cordova.js will need to live with your server pages, and any plugins, and cordova_plugins.js and all plugin files must match the versions of the native implementation that is compiled in the app. 2. Yes, it is a great way of testing, as you can skip the whole build, and just reload. If the app should function with/without the feature, then yes, it should detect it. 3. Similar to what you describe in #2, for targeting browsers generically. [1] 2.12 Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected. https://developer.apple.com/appstore/resources/approval/guidelines.html Cheers, Jesse @purplecabbage risingj.com On Fri, Jun 6, 2014 at 1:02 PM, Jeff Burtoft jeffb...@microsoft.com wrote: I have a tool that allows developers to take their web apps and build them into hosted store apps on Windows 8.1 and Windows Phone (8 and 8.1) called the Web App Templatehttps://wat.codeplex.com/. Some of the developers who are using the tool would like to see it go cross platform to Android and iOS, so that the same config file could be used to build hosted apps for the play store and App store just as it is on Windows. I love the idea of going cross platform, and when I think cross platform, I think Cordova, but after looking through some of the documentation, I'm not sure if it's a good fit. I'm looking for some direction on these questions: 1. Does Cordova have hosted apps (where the content lives on the server as opposed to being packaged with the app) in its roadmap? I realize you can do this today on most platforms with a redirect, but it seems to be more of a work around rather than a strategy. 2. Does it make sense to make Cordova device APIs available to hosted apps? In general these apps also must function in a browser , so the features would have to be implemented in a progressive enhancement model. 3. I see a build for Browser https://github.com/apache/cordova-browser on the Cordova website. What are the plans for this build? Can anyone help clarify some of this? Thanks, Jeff Burtoft HTML5 Evangelist \\ Web Technologies \\ Microsoft
Re: minor bump to cordova-lib
good. lord. On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny mmo...@chromium.org wrote: We all wish! On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer lorin.b...@gmail.com wrote: Michal: the root package.json is being removed. I do want to perform an npm publish with a patch version increment, so downstream projects can reference include by npm registry and not git url. That would constitute a 'release' of some sort. My understanding was that bug patches of this sort could be pushed out with minimum fuss. On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny mmo...@chromium.org wrote: In particular, I thought the root of the repo wasn't supposed to be a node package, but a bucket for multiple node packages. (ie, should not be a package.json at the root). We don't vote on commits (though its nice to ask for review for big hairy patches like this one, so thanks for that). -Michal On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve agri...@chromium.org wrote: I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: minor bump to cordova-lib
Going to have to do a vote to release to npm. On Mon, Jun 9, 2014 at 1:22 PM, Lorin Beer lorin.b...@gmail.com wrote: good. lord. On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny mmo...@chromium.org wrote: We all wish! On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer lorin.b...@gmail.com wrote: Michal: the root package.json is being removed. I do want to perform an npm publish with a patch version increment, so downstream projects can reference include by npm registry and not git url. That would constitute a 'release' of some sort. My understanding was that bug patches of this sort could be pushed out with minimum fuss. On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny mmo...@chromium.org wrote: In particular, I thought the root of the repo wasn't supposed to be a node package, but a bucket for multiple node packages. (ie, should not be a package.json at the root). We don't vote on commits (though its nice to ask for review for big hairy patches like this one, so thanks for that). -Michal On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve agri...@chromium.org wrote: I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: Cordova and w3c spec Algnment - Vibration Gap Analysis
Doing an automated check sounds great in theory, and would be cool to make the check part of mobile-spec (or its successors). However, I wonder how well the nuances in the standards would be detected, such as the cancelling of outstanding vibrations as listed in Lisa’s gap analysis doc. It’s more than a syntactical alignment, it shoud be semantic also. On Jun 9, 2014, at 1:44 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Here is some work that we have been doing - https://github.com/MSOpenTech/cordova-api-audit/compare/w3 As you can see from the diff, there were 2 approaches we took and would like feedback from folks here on the best approach to move forward with 1. Automated a. Picked up type definitions for Cordova plugins from definatelytyped.org b. Generated Typescript bindings from the W3C IDL for each of the spec c. Checked each into its own branch, can now do a git style diff, showing the exact differences - look at the contacts.d.ts file for the diffs in the contacts API. d. Since this is utomatic, can cover more ground quickly, we just need to tweak the output at the end - things like Object.getSetter, etc. We are working on those now. e. Given that this is hosted on github, this can be easily updated as we continue to change the API f.Can also facilitate inline discussions
RE: Cordova and w3c spec Algnment - Vibration Gap Analysis
Meant to say that automated is how we started, and then dug deeper into the semantics. We were looking at using github to document these. -Original Message- From: Marcel Kinard [mailto:cmarc...@gmail.com] Sent: Monday, June 9, 2014 1:29 PM To: dev@cordova.apache.org Subject: Re: Cordova and w3c spec Algnment - Vibration Gap Analysis Doing an automated check sounds great in theory, and would be cool to make the check part of mobile-spec (or its successors). However, I wonder how well the nuances in the standards would be detected, such as the cancelling of outstanding vibrations as listed in Lisa's gap analysis doc. It's more than a syntactical alignment, it shoud be semantic also. On Jun 9, 2014, at 1:44 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Here is some work that we have been doing - https://github.com/MSOpenTech/cordova-api-audit/compare/w3 As you can see from the diff, there were 2 approaches we took and would like feedback from folks here on the best approach to move forward with 1. Automated a. Picked up type definitions for Cordova plugins from definatelytyped.org b. Generated Typescript bindings from the W3C IDL for each of the spec c. Checked each into its own branch, can now do a git style diff, showing the exact differences - look at the contacts.d.ts file for the diffs in the contacts API. d. Since this is utomatic, can cover more ground quickly, we just need to tweak the output at the end - things like Object.getSetter, etc. We are working on those now. e. Given that this is hosted on github, this can be easily updated as we continue to change the API f.Can also facilitate inline discussions
Re: minor bump to cordova-lib
My understanding is that a VOTE was for ./dist and that anything npm is the domain of the person publishing. On Mon, Jun 9, 2014 at 1:27 PM, Steven Gill stevengil...@gmail.com wrote: Going to have to do a vote to release to npm. On Mon, Jun 9, 2014 at 1:22 PM, Lorin Beer lorin.b...@gmail.com wrote: good. lord. On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny mmo...@chromium.org wrote: We all wish! On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer lorin.b...@gmail.com wrote: Michal: the root package.json is being removed. I do want to perform an npm publish with a patch version increment, so downstream projects can reference include by npm registry and not git url. That would constitute a 'release' of some sort. My understanding was that bug patches of this sort could be pushed out with minimum fuss. On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny mmo...@chromium.org wrote: In particular, I thought the root of the repo wasn't supposed to be a node package, but a bucket for multiple node packages. (ie, should not be a package.json at the root). We don't vote on commits (though its nice to ask for review for big hairy patches like this one, so thanks for that). -Michal On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve agri...@chromium.org wrote: I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer lorin.b...@gmail.com wrote: Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin
Re: [VOTE] Plugins Release (attempt 2)
I also verified the contents of the zip files against my local repos at that hash (diff -r). All looks good. On Jun 9, 2014, at 3:33 PM, Marcel Kinard cmarc...@gmail.com wrote: +1 - Ran coho audit-license-headers, all looks good. - Ran coho verify-tags, all looks good. - Ran mobile-spec using Android Cordova platform 3.5.0 on Android 4.4.3. Ignoring the fails in Battery and Contacts, I see 2 other failing tests in Geolocation which I am tempted to ignore because this plugin is empty for Android since it falls back to the webview implementation for geolocation. On Jun 9, 2014, at 1:48 PM, Steven Gill stevengil...@gmail.com wrote: cordova-plugin-camera: 0.3.0 (4fa934e06f) cordova-plugin-console: 0.2.9 (f3764d8318) cordova-plugin-device: 0.2.10 (159d55eb1d) cordova-plugin-device-motion: 0.2.8 (51d58d6d29) cordova-plugin-device-orientation: 0.3.7 (d66777a007) cordova-plugin-dialogs: 0.2.8 (057d6cc4e9) cordova-plugin-file: 1.2.0 (e02d3d0f8e) cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8) cordova-plugin-geolocation: 0.3.8 (a403b4abb6) cordova-plugin-globalization: 0.2.8 (9a4e8c81e5) cordova-plugin-inappbrowser: 0.5.0 (992306bbc5) cordova-plugin-media: 0.2.11 (ee68987d3b) cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3) cordova-plugin-network-information: 0.2.9 (be5875f9d9) cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab) cordova-plugin-statusbar: 0.1.6 (11195658af) cordova-plugin-vibration: 0.3.9 (b2fdbc1c92)
Re: minor bump to cordova-lib
On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux b...@brian.io wrote: My understanding is that a VOTE was for ./dist and that anything npm is the domain of the person publishing. Here's the policy: http://www.apache.org/dev/release#what What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. [...] So it's not that packages published to npm (or any other downstream distribution channel) don't require a VOTE, it's that npm packages should also be published to dist (and require a VOTE). Marvin Humphrey
Re: minor bump to cordova-lib
/me slow clap On Mon, Jun 9, 2014 at 1:57 PM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux b...@brian.io wrote: My understanding is that a VOTE was for ./dist and that anything npm is the domain of the person publishing. Here's the policy: http://www.apache.org/dev/release#what What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. [...] So it's not that packages published to npm (or any other downstream distribution channel) don't require a VOTE, it's that npm packages should also be published to dist (and require a VOTE). Marvin Humphrey
Re: minor bump to cordova-lib
And this is why we rarely release anything anymore. On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux b...@brian.io wrote: /me slow clap On Mon, Jun 9, 2014 at 1:57 PM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux b...@brian.io wrote: My understanding is that a VOTE was for ./dist and that anything npm is the domain of the person publishing. Here's the policy: http://www.apache.org/dev/release#what What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. [...] So it's not that packages published to npm (or any other downstream distribution channel) don't require a VOTE, it's that npm packages should also be published to dist (and require a VOTE). Marvin Humphrey
[GitHub] cordova-plugin-device-motion pull request: CB-6888 Polish translat...
Github user ldeluca commented on the pull request: https://github.com/apache/cordova-plugin-device-motion/pull/13#issuecomment-45548352 Yes, please use crowdin. We don't accept individual language pull requests. The crowdin tool handles translation for Cordova. See: crowdin.net/project/cordova or email me if you have questions. @zalun Thanks @rodms10 --- 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. ---
bugs with components and subtasks for the same components
https://issues.apache.org/jira/browse/CB-4650 is currently unresolved. Unfortunately, it shows up when I search for open blackberry bugs. It has 5 subtasks, 4 of which are done. I'd like to (as a policy) remove all platform tags from meta bugs when there's a subtask specific to that platform. Any objections?
Re: bugs with components and subtasks for the same components
+1 On Mon, Jun 9, 2014 at 2:57 PM, Josh Soref jso...@blackberry.com wrote: https://issues.apache.org/jira/browse/CB-4650 is currently unresolved. Unfortunately, it shows up when I search for open blackberry bugs. It has 5 subtasks, 4 of which are done. I'd like to (as a policy) remove all platform tags from meta bugs when there's a subtask specific to that platform. Any objections?
Re: [WP8][cordova-plugin-file] filesystem: null after use IsolatedStorageFile.MoveDirectory
Thanks Martin, is this captured in a JIRA issue just in case people are away and this thread gets buried? On Mon, Jun 9, 2014 at 10:39 AM, Martin Gonzalez martin.c.glez.g...@gmail.com wrote: I'm working on fix mobile spec automated tests, specifically on those which involves the File plugin. In the test # 67 of that test suite, I've found out that the problem is not that the directory is not moved, the problem is that after this line is executed: https://github.com/apache/cordova-plugin-file/blob/master/src/wp/File.cs#L1412 The DispatchCommandResult sends the entry file with the CallbackID, but the problem is that the information about the filesystem is missing. This situation it doesn't happen when isoFile.MoveFile(newPath), IsolatedStorageFile.CreateDirectory(path) or IsolatedStorageFile.CreateFile(path) are used the filesystem information it remains with those but not with MoveDirectory. During the 67 test and several others, it uses the filesystem information of the recent moved directory to determine if the file exists, and when it gets to GeFileOrDirectory on the options this is the array obtained: [null,file1,{\create\:false},File619232322] When Create or MoveFile: [\/\/entry,move.dsp.srcDir,file1,{\create\:false},File619232322] From the JS side object: MoveDirectory: {isFile:false, isDirectory:true, name : entry.move.dsp.dstDir, filesystem:null, nativeURL:null} MoveFile: {isFile:true, isDirectory:false, name : entry.move.dsp.dstDir, filesystem:FileSystem: persistent, nativeURL:null} That's the reason why some automated tests on the MoveTo section are failing. Tested on Windows Phone 8 and 8.1, emulator and device. Same behavior. Any thoughts about this? -- Regards, Martin Gonzalez
Re: bugs with components and subtasks for the same components
+1 I have removed everything except wp8 also btw. my question in the comments remains unanswered ... @purplecabbage risingj.com On Mon, Jun 9, 2014 at 2:59 PM, Shazron shaz...@gmail.com wrote: +1 On Mon, Jun 9, 2014 at 2:57 PM, Josh Soref jso...@blackberry.com wrote: https://issues.apache.org/jira/browse/CB-4650 is currently unresolved. Unfortunately, it shows up when I search for open blackberry bugs. It has 5 subtasks, 4 of which are done. I'd like to (as a policy) remove all platform tags from meta bugs when there's a subtask specific to that platform. Any objections?
Re: minor bump to cordova-lib
On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux b...@brian.io wrote: /me slow clap Brian, I realize that you are deeply opposed to voting on releases, and I understand and respect your arguments. Were Cordova an independent project, I would not come to the community proposing that release voting be adopted. However, Cordova is at Apache and the policies are what they are. You're welcome to make the case that the org should change, but to be honest I doubt such a change is achievable in the near term. The policy has deep roots -- a good chunk of the Foundation's legal structure is built in its service. And so I would argue that avoiding quixotic conflicts with the Board is in the best interest of most Cordova stakeholders. In the meantime, the question is how to make the best of things within existing constraints. For the record, there's nothing stopping Cordova from releasing on a fixed cadence. Marvin Humphrey
Re: [WP8][cordova-plugin-file] filesystem: null after use IsolatedStorageFile.MoveDirectory
Sure no problem, and CB-6901 is the issue with all the information related. On Jun 9, 2014 5:06 PM, Jesse purplecabb...@gmail.com wrote: Yes, thanks Martin. The issue you created is sufficient. CB-6901 @purplecabbage risingj.com On Mon, Jun 9, 2014 at 3:00 PM, Shazron shaz...@gmail.com wrote: Thanks Martin, is this captured in a JIRA issue just in case people are away and this thread gets buried? On Mon, Jun 9, 2014 at 10:39 AM, Martin Gonzalez martin.c.glez.g...@gmail.com wrote: I'm working on fix mobile spec automated tests, specifically on those which involves the File plugin. In the test # 67 of that test suite, I've found out that the problem is not that the directory is not moved, the problem is that after this line is executed: https://github.com/apache/cordova-plugin-file/blob/master/src/wp/File.cs#L1412 The DispatchCommandResult sends the entry file with the CallbackID, but the problem is that the information about the filesystem is missing. This situation it doesn't happen when isoFile.MoveFile(newPath), IsolatedStorageFile.CreateDirectory(path) or IsolatedStorageFile.CreateFile(path) are used the filesystem information it remains with those but not with MoveDirectory. During the 67 test and several others, it uses the filesystem information of the recent moved directory to determine if the file exists, and when it gets to GeFileOrDirectory on the options this is the array obtained: [null,file1,{\create\:false},File619232322] When Create or MoveFile: [\/\/entry,move.dsp.srcDir,file1,{\create\:false},File619232322] From the JS side object: MoveDirectory: {isFile:false, isDirectory:true, name : entry.move.dsp.dstDir, filesystem:null, nativeURL:null} MoveFile: {isFile:true, isDirectory:false, name : entry.move.dsp.dstDir, filesystem:FileSystem: persistent, nativeURL:null} That's the reason why some automated tests on the MoveTo section are failing. Tested on Windows Phone 8 and 8.1, emulator and device. Same behavior. Any thoughts about this? -- Regards, Martin Gonzalez
Re: Coho updates
This is great, thanks Andrew. One further enhancement would be to verify the source zip vs downloading the source at the tag, whether there are any differences (would help with release) On Fri, Jun 6, 2014 at 9:18 AM, Andrew Grieve agri...@chromium.org wrote: Spent some time on it yesterday today. Highlights: - Much faster start-up on node 0.10 (made some requires lazy) - Much faster repo-clone and repo-update commands (made network work concurrent) - Clearer output for repo-status command (prints nothing for no changes, prints unpushed changes uncommitted files) - Added a verify-tags command, so you can paste in Steve's plugins release vote email and it will check that all the tags match the hashes.
Re: minor bump to cordova-lib
Blind copy paste of URLs and blanket repeat emails are not helping either. We can and do VOTE on artifacts. (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast votes as tags like we used to. A topic for the board and members to debate to be sure.) Your earlier emails demonstrate well how little you understand of the project. I'd recommend *actually* building Cordova *then* providing advice about how to improve it and our release process. Seriously: it would help. On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux b...@brian.io wrote: /me slow clap Brian, I realize that you are deeply opposed to voting on releases, and I understand and respect your arguments. Were Cordova an independent project, I would not come to the community proposing that release voting be adopted. However, Cordova is at Apache and the policies are what they are. You're welcome to make the case that the org should change, but to be honest I doubt such a change is achievable in the near term. The policy has deep roots -- a good chunk of the Foundation's legal structure is built in its service. And so I would argue that avoiding quixotic conflicts with the Board is in the best interest of most Cordova stakeholders. In the meantime, the question is how to make the best of things within existing constraints. For the record, there's nothing stopping Cordova from releasing on a fixed cadence. Marvin Humphrey
[cordova-docs] Vagrant Support to Simplify Doc Generation
Hey all, I know a lot of us have trouble generating the documentation. Juggling Ruby environments and the dependencies can be a sensitive matter. To make our lives easier, I've added Vagrant support to our documentation generator [1]. It's easy to setup and works on all the major operating systems. After you've installed Vagrant and VirtualBox, you only need to run one command to download and provision a light-weight virtual machine (approx 200MB): $ vagrant up C:\ vagrant up Once the virtual machine has been provisioned, you can connect to it through a SSH tunnel and access your cordova-docs repository, which is shared between the virtual and local machines: $ vagrant ssh $ cd /vagrant $ ls # contents of cordova-docs repo From here, you can run any cordova-docs command, such as: $ ./bin/generate You'll see the files appear on both your local and virtual machine. You can read the full details in the README.md [2] I hope this helps to make doc generation a little easier. Cheers, Michael [1] https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=e1030bb90fe478f11078c11485161e4abb1cdb4d [2] https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blob;f=README.md;h=5e65910b54425cc82c798546d74bb94f6ee2058e;hb=HEAD#l80
Re: minor bump to cordova-lib
Marvin's email came across to me as respectful. Brian and Joe - your responses came across as disrespectful to me. Slow claps and sarcasm should probably be avoided in email. This issue has been covered at length, and the a very clear conclusion was made that unless policies change, anything published to npm that is intended for users outside of the project must first land on dist/. On Mon, Jun 9, 2014 at 6:38 PM, Brian LeRoux b...@brian.io wrote: Blind copy paste of URLs and blanket repeat emails are not helping either. We can and do VOTE on artifacts. (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast votes as tags like we used to. A topic for the board and members to debate to be sure.) Your earlier emails demonstrate well how little you understand of the project. I'd recommend *actually* building Cordova *then* providing advice about how to improve it and our release process. Seriously: it would help. On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux b...@brian.io wrote: /me slow clap Brian, I realize that you are deeply opposed to voting on releases, and I understand and respect your arguments. Were Cordova an independent project, I would not come to the community proposing that release voting be adopted. However, Cordova is at Apache and the policies are what they are. You're welcome to make the case that the org should change, but to be honest I doubt such a change is achievable in the near term. The policy has deep roots -- a good chunk of the Foundation's legal structure is built in its service. And so I would argue that avoiding quixotic conflicts with the Board is in the best interest of most Cordova stakeholders. In the meantime, the question is how to make the best of things within existing constraints. For the record, there's nothing stopping Cordova from releasing on a fixed cadence. Marvin Humphrey
Re: Coho updates
Agreed. If no one else gets to it, I'll probably add that next time I go to verify archive contents. On Mon, Jun 9, 2014 at 6:38 PM, Shazron shaz...@gmail.com wrote: This is great, thanks Andrew. One further enhancement would be to verify the source zip vs downloading the source at the tag, whether there are any differences (would help with release) On Fri, Jun 6, 2014 at 9:18 AM, Andrew Grieve agri...@chromium.org wrote: Spent some time on it yesterday today. Highlights: - Much faster start-up on node 0.10 (made some requires lazy) - Much faster repo-clone and repo-update commands (made network work concurrent) - Clearer output for repo-status command (prints nothing for no changes, prints unpushed changes uncommitted files) - Added a verify-tags command, so you can paste in Steve's plugins release vote email and it will check that all the tags match the hashes.
[GitHub] cordova-firefoxos pull request: add icons
Github user marti1125 commented on the pull request: https://github.com/apache/cordova-firefoxos/pull/13#issuecomment-45569697 When I added firefoxos platform, I got this problem with defaults.xml ![cordovafirefoxosapp7](https://cloud.githubusercontent.com/assets/223240/3225302/1739299a-f04d-11e3-9eba-1bc974bcc294.png) this is the app example: https://www.dropbox.com/s/e051pchajv0q3o5/myapp.zip and finally the icons ![firefoxosappnewicons](https://cloud.githubusercontent.com/assets/223240/3225316/88cee310-f04d-11e3-961a-979e246bbb40.png) --- 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. ---
[GitHub] cordova-plugin-network-information pull request: fix NullPointerEx...
GitHub user dozer47528 opened a pull request: https://github.com/apache/cordova-plugin-network-information/pull/10 fix NullPointerException crash when the info is null! You can merge this pull request into a Git repository by running: $ git pull https://github.com/dozer47528/cordova-plugin-network-information master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-network-information/pull/10.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 #10 commit 99b7676845530845c733eb79c728a86e05fc37bc Author: Dozer m...@dozer.cc Date: 2014-06-10T03:15:33Z fix NullPointerException crash when the info is null! --- 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. ---
Re: minor bump to cordova-lib
first what? A hotfix On Jun 9, 2014 6:33 PM, Andrew Grieve agri...@chromium.org wrote: Marvin's email came across to me as respectful. Brian and Joe - your responses came across as disrespectful to me. Slow claps and sarcasm should probably be avoided in email. This issue has been covered at length, and the a very clear conclusion was made that unless policies change, anything published to npm that is intended for users outside of the project must first land on dist/. On Mon, Jun 9, 2014 at 6:38 PM, Brian LeRoux b...@brian.io wrote: Blind copy paste of URLs and blanket repeat emails are not helping either. We can and do VOTE on artifacts. (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast votes as tags like we used to. A topic for the board and members to debate to be sure.) Your earlier emails demonstrate well how little you understand of the project. I'd recommend *actually* building Cordova *then* providing advice about how to improve it and our release process. Seriously: it would help. On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux b...@brian.io wrote: /me slow clap Brian, I realize that you are deeply opposed to voting on releases, and I understand and respect your arguments. Were Cordova an independent project, I would not come to the community proposing that release voting be adopted. However, Cordova is at Apache and the policies are what they are. You're welcome to make the case that the org should change, but to be honest I doubt such a change is achievable in the near term. The policy has deep roots -- a good chunk of the Foundation's legal structure is built in its service. And so I would argue that avoiding quixotic conflicts with the Board is in the best interest of most Cordova stakeholders. In the meantime, the question is how to make the best of things within existing constraints. For the record, there's nothing stopping Cordova from releasing on a fixed cadence. Marvin Humphrey