Re: Release Masters?
Is there any position for something like Release/Component Apprentice? :-) Just in case a Master wants to train, delegate, have someone to cover for vacation, or slap :-p, etc.. I will be interested to be apprentice since I'm getting started in the community --Carlos On Tue, Jun 18, 2013 at 3:23 PM, Shazron shaz...@gmail.com wrote: Thanks James! Most of it is on the wiki, and is pretty straightforward: Not surprisingly, I made OS X (almost) the same as iOS in structure as well: http://wiki.apache.org/cordova/IOSReleaseChecklist Some of the task should be covered in the JIRA issues generated I think. On Tue, Jun 18, 2013 at 10:30 AM, James Jong wjamesj...@gmail.com wrote: Shaz, I haven't done it before but I'll be happy to work with you and help when you're out for iOS OS X. FYI for planning, I will be out away on vacation June 26-July 15. -James Jong On Jun 18, 2013, at 1:18 PM, Andrew Grieve agri...@chromium.org wrote: Okay, created a new release bug sub-tasks here: https://issues.apache.org/jira/browse/CB-3906 If you want to own a component, just assign it to yourself. On Tue, Jun 18, 2013 at 12:33 PM, Shazron shaz...@gmail.com wrote: Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take over if they wish. What I'm interested in is who should be the second in case I can't do it (for example I am away almost all of August). Technically anyone can take over but it will be nice if they are up to speed and have the necessary environment to test as a 'second'.. On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj f...@adobe.com wrote: I am the lead for cordova-js in JIRA that anyone else can take over if they wish. My focus is more on the tooling nowadays. Lots of features/improvements/wishes in that component.. On 6/18/13 9:02 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 18, 2013, at 5:07 AM, Brian LeRoux b...@brian.io wrote: Think we already have this as per the issue tracker concept of 'leads' but I do agree formalizing the role a little more would help. Do all the components leads (as listed in Jira) want to be release masters for their components? If not, James Jong and I could probably own the release master role for a component each, in case any one is looking to unload that. -- Carlos Santana csantan...@gmail.com
Re: Release Masters?
Ideally, all release steps are documented on the Wiki, and all progress made during a release is reported in the release JIRA issues. So, I think you'd get most of the way there by monitoring the issues commits read the wiki. If there's anything you're in doubt about, then there's a good chance you're not alone and an email to the list would be great :) On Wed, Jun 19, 2013 at 7:44 AM, Carlos Santana csantan...@gmail.comwrote: Is there any position for something like Release/Component Apprentice? :-) Just in case a Master wants to train, delegate, have someone to cover for vacation, or slap :-p, etc.. I will be interested to be apprentice since I'm getting started in the community --Carlos On Tue, Jun 18, 2013 at 3:23 PM, Shazron shaz...@gmail.com wrote: Thanks James! Most of it is on the wiki, and is pretty straightforward: Not surprisingly, I made OS X (almost) the same as iOS in structure as well: http://wiki.apache.org/cordova/IOSReleaseChecklist Some of the task should be covered in the JIRA issues generated I think. On Tue, Jun 18, 2013 at 10:30 AM, James Jong wjamesj...@gmail.com wrote: Shaz, I haven't done it before but I'll be happy to work with you and help when you're out for iOS OS X. FYI for planning, I will be out away on vacation June 26-July 15. -James Jong On Jun 18, 2013, at 1:18 PM, Andrew Grieve agri...@chromium.org wrote: Okay, created a new release bug sub-tasks here: https://issues.apache.org/jira/browse/CB-3906 If you want to own a component, just assign it to yourself. On Tue, Jun 18, 2013 at 12:33 PM, Shazron shaz...@gmail.com wrote: Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take over if they wish. What I'm interested in is who should be the second in case I can't do it (for example I am away almost all of August). Technically anyone can take over but it will be nice if they are up to speed and have the necessary environment to test as a 'second'.. On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj f...@adobe.com wrote: I am the lead for cordova-js in JIRA that anyone else can take over if they wish. My focus is more on the tooling nowadays. Lots of features/improvements/wishes in that component.. On 6/18/13 9:02 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 18, 2013, at 5:07 AM, Brian LeRoux b...@brian.io wrote: Think we already have this as per the issue tracker concept of 'leads' but I do agree formalizing the role a little more would help. Do all the components leads (as listed in Jira) want to be release masters for their components? If not, James Jong and I could probably own the release master role for a component each, in case any one is looking to unload that. -- Carlos Santana csantan...@gmail.com
Apache VM for Medic's CouchDB
Hello everyone, I have been working the last week on getting medic up and running here at our office, and so far things are going pretty well. I would like to start contributing our tests back to the community pretty soon. However, I contacted Fil about flowing our test results back to the CI database, and he informed me that unfortunately the EC2 instance has been removed. I would like to propose that we have the Apache folks set us up with a standard Linux VM that we can use to host the CouchDB server to collect test results. Using an Apache VM seems to be more in the Apache spirit as opposed to an EC2 instance. Since it would be more centralized and community owned, it would potentially make it easier for other groups to contribute test results. The VM can also serve as a home for any future dumps or hosted scripts that we need. Any thoughts on this? If there are no problems, then can somebody involved with ASF help me create the relevant INFRA issues? Thanks, Mike Billau
Re: Apache VM for Medic's CouchDB
Sounds great! On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau mike.bil...@gmail.com wrote: Hello everyone, I have been working the last week on getting medic up and running here at our office, and so far things are going pretty well. I would like to start contributing our tests back to the community pretty soon. However, I contacted Fil about flowing our test results back to the CI database, and he informed me that unfortunately the EC2 instance has been removed. I would like to propose that we have the Apache folks set us up with a standard Linux VM that we can use to host the CouchDB server to collect test results. Using an Apache VM seems to be more in the Apache spirit as opposed to an EC2 instance. Since it would be more centralized and community owned, it would potentially make it easier for other groups to contribute test results. The VM can also serve as a home for any future dumps or hosted scripts that we need. Any thoughts on this? If there are no problems, then can somebody involved with ASF help me create the relevant INFRA issues? Thanks, Mike Billau
Re: Cordova.js now at 2.9.0rc1 for real
I've been seeing similar issues with Jake since I've upgraded my node and it is definitely related to Jake failing with dependencies. I have yet to find the real root cause. On 13-06-18 8:27 PM, Andrew Grieve agri...@chromium.org wrote: As both Jesse and Shaz pointed out, I ran coho to update cordova.js snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. This is now fixed (new commits for 2.9.0rc1), and I've updated the coho script to not push by default (so that commits can be inspected). The root problem is that jake is existing without failure and without printing anything to the console. Can anyone else verify if this is happening for them? I debugged it as far as to see that removing the complainwhitespace dependency from the hint task fixed things, but I don't know why that is. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Cordova.js now at 2.9.0rc1 for real
This happened to me back when I upgraded node. I ended up doing rm -rf node_modules and then npm install. I eventually managed to claw my way back to a working Jake. Why it fails utterly silently, and with code 0, puzzles me. Braden On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: I've been seeing similar issues with Jake since I've upgraded my node and it is definitely related to Jake failing with dependencies. I have yet to find the real root cause. On 13-06-18 8:27 PM, Andrew Grieve agri...@chromium.org wrote: As both Jesse and Shaz pointed out, I ran coho to update cordova.js snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. This is now fixed (new commits for 2.9.0rc1), and I've updated the coho script to not push by default (so that commits can be inspected). The root problem is that jake is existing without failure and without printing anything to the console. Can anyone else verify if this is happening for them? I debugged it as far as to see that removing the complainwhitespace dependency from the hint task fixed things, but I don't know why that is. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
any one going to //build
Any folks going to be at the //build conference in sf next week, hit me up and lets grab a drink or 2. mw
Re: Release Masters?
Sure thing. I'll use 2.9 as a dry run for me. FYI, I updated the broken links in the checklist that were pointing to incubator. -James Jong On Jun 18, 2013, at 3:23 PM, Shazron shaz...@gmail.com wrote: Thanks James! Most of it is on the wiki, and is pretty straightforward: Not surprisingly, I made OS X (almost) the same as iOS in structure as well: http://wiki.apache.org/cordova/IOSReleaseChecklist Some of the task should be covered in the JIRA issues generated I think. On Tue, Jun 18, 2013 at 10:30 AM, James Jong wjamesj...@gmail.com wrote: Shaz, I haven't done it before but I'll be happy to work with you and help when you're out for iOS OS X. FYI for planning, I will be out away on vacation June 26-July 15. -James Jong On Jun 18, 2013, at 1:18 PM, Andrew Grieve agri...@chromium.org wrote: Okay, created a new release bug sub-tasks here: https://issues.apache.org/jira/browse/CB-3906 If you want to own a component, just assign it to yourself. On Tue, Jun 18, 2013 at 12:33 PM, Shazron shaz...@gmail.com wrote: Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take over if they wish. What I'm interested in is who should be the second in case I can't do it (for example I am away almost all of August). Technically anyone can take over but it will be nice if they are up to speed and have the necessary environment to test as a 'second'.. On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj f...@adobe.com wrote: I am the lead for cordova-js in JIRA that anyone else can take over if they wish. My focus is more on the tooling nowadays. Lots of features/improvements/wishes in that component.. On 6/18/13 9:02 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 18, 2013, at 5:07 AM, Brian LeRoux b...@brian.io wrote: Think we already have this as per the issue tracker concept of 'leads' but I do agree formalizing the role a little more would help. Do all the components leads (as listed in Jira) want to be release masters for their components? If not, James Jong and I could probably own the release master role for a component each, in case any one is looking to unload that.
Re: CLI: suggested change to platform ls command
Great idea to expand the output. I do prefer the explicit `ls` and would rather have the default be --help. Given that, `ls` is harmless, so I don't much mind. On Tue, Jun 18, 2013 at 1:36 PM, Michael Brooks mich...@michaelbrooks.cawrote: I think [1] is up to the command patterns that cordova-cli uses. As far as I know, it doesn't use any other shortcuted commands. ls is not a highly used command, so a shortcut isn't necessary. I think [2] make sense to implement. Michael On Tue, Jun 18, 2013 at 10:14 AM, Filip Maj f...@adobe.com wrote: I had two issues submitted recently, for suggestions to tweaking that particular command/api: [1]: remove the explicit ls command [2]: have platform(s) by itself be the ls command, and expand on what it returns. Not only the currently-installed platforms for a project, but also which platforms are available and unavailable to install (I.e. Ones where the check_requirements script passes/fails). Thoughts? [1] https://issues.apache.org/jira/browse/CB-3903 [2] https://issues.apache.org/jira/browse/CB-3904
Re: Apache VM for Medic's CouchDB
Would love to see this, thanks for taking the initiative on this Mike! On 6/19/13 7:19 AM, Andrew Grieve agri...@chromium.org wrote: Sounds great! On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau mike.bil...@gmail.com wrote: Hello everyone, I have been working the last week on getting medic up and running here at our office, and so far things are going pretty well. I would like to start contributing our tests back to the community pretty soon. However, I contacted Fil about flowing our test results back to the CI database, and he informed me that unfortunately the EC2 instance has been removed. I would like to propose that we have the Apache folks set us up with a standard Linux VM that we can use to host the CouchDB server to collect test results. Using an Apache VM seems to be more in the Apache spirit as opposed to an EC2 instance. Since it would be more centralized and community owned, it would potentially make it easier for other groups to contribute test results. The VM can also serve as a home for any future dumps or hosted scripts that we need. Any thoughts on this? If there are no problems, then can somebody involved with ASF help me create the relevant INFRA issues? Thanks, Mike Billau
Re: Cordova.js now at 2.9.0rc1 for real
hmm, I did indeed just upgrade my node version. blowing away node_modules didn't seem to fix it though. On Wed, Jun 19, 2013 at 12:04 PM, Braden Shepherdson bra...@chromium.orgwrote: This happened to me back when I upgraded node. I ended up doing rm -rf node_modules and then npm install. I eventually managed to claw my way back to a working Jake. Why it fails utterly silently, and with code 0, puzzles me. Braden On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: I've been seeing similar issues with Jake since I've upgraded my node and it is definitely related to Jake failing with dependencies. I have yet to find the real root cause. On 13-06-18 8:27 PM, Andrew Grieve agri...@chromium.org wrote: As both Jesse and Shaz pointed out, I ran coho to update cordova.js snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. This is now fixed (new commits for 2.9.0rc1), and I've updated the coho script to not push by default (so that commits can be inspected). The root problem is that jake is existing without failure and without printing anything to the console. Can anyone else verify if this is happening for them? I debugged it as far as to see that removing the complainwhitespace dependency from the hint task fixed things, but I don't know why that is. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Cordova.js now at 2.9.0rc1 for real
I use nvm to switch back to node v0.8.14 when running jake on cordova-js. Not a good solution. On Wed, Jun 19, 2013 at 11:08 AM, Andrew Grieve agri...@chromium.orgwrote: hmm, I did indeed just upgrade my node version. blowing away node_modules didn't seem to fix it though. On Wed, Jun 19, 2013 at 12:04 PM, Braden Shepherdson bra...@chromium.org wrote: This happened to me back when I upgraded node. I ended up doing rm -rf node_modules and then npm install. I eventually managed to claw my way back to a working Jake. Why it fails utterly silently, and with code 0, puzzles me. Braden On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: I've been seeing similar issues with Jake since I've upgraded my node and it is definitely related to Jake failing with dependencies. I have yet to find the real root cause. On 13-06-18 8:27 PM, Andrew Grieve agri...@chromium.org wrote: As both Jesse and Shaz pointed out, I ran coho to update cordova.js snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. This is now fixed (new commits for 2.9.0rc1), and I've updated the coho script to not push by default (so that commits can be inspected). The root problem is that jake is existing without failure and without printing anything to the console. Can anyone else verify if this is happening for them? I debugged it as far as to see that removing the complainwhitespace dependency from the hint task fixed things, but I don't know why that is. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Cordova.js now at 2.9.0rc1 for real
One further piece of information for this Node version nonsense: 0.6 is too old. 0.8 is too old, but only very thinly: we call os.tmpdir(), which exists only in 0.10, renamed from os.tmpDir() in 0.8. os.tmpDir() still exists as a synonym in 0.10 (though I don't think it appears in the documentation, it's clearly there in the source), so we can change the spelling of these few calls and return our support for Node 0.8 in the CLI tools. I think this is probably a good idea. Braden On Wed, Jun 19, 2013 at 2:17 PM, Steven Gill stevengil...@gmail.com wrote: I use nvm to switch back to node v0.8.14 when running jake on cordova-js. Not a good solution. On Wed, Jun 19, 2013 at 11:08 AM, Andrew Grieve agri...@chromium.org wrote: hmm, I did indeed just upgrade my node version. blowing away node_modules didn't seem to fix it though. On Wed, Jun 19, 2013 at 12:04 PM, Braden Shepherdson bra...@chromium.org wrote: This happened to me back when I upgraded node. I ended up doing rm -rf node_modules and then npm install. I eventually managed to claw my way back to a working Jake. Why it fails utterly silently, and with code 0, puzzles me. Braden On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: I've been seeing similar issues with Jake since I've upgraded my node and it is definitely related to Jake failing with dependencies. I have yet to find the real root cause. On 13-06-18 8:27 PM, Andrew Grieve agri...@chromium.org wrote: As both Jesse and Shaz pointed out, I ran coho to update cordova.js snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. This is now fixed (new commits for 2.9.0rc1), and I've updated the coho script to not push by default (so that commits can be inspected). The root problem is that jake is existing without failure and without printing anything to the console. Can anyone else verify if this is happening for them? I debugged it as far as to see that removing the complainwhitespace dependency from the hint task fixed things, but I don't know why that is. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Documentation update to previous version
Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron shaz...@gmail.com wrote: Yeah I'm interested in the flow as well. I think we published everything again in older releases, not sure if we are still doing that going forward On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 17, 2013, at 6:21 PM, Shazron shaz...@gmail.com wrote: Should I bother? I know they will go in edge. There are a couple of issues: https://issues.apache.org/jira/browse/CB-3753 https://issues.apache.org/jira/browse/CB-3752 Basically it's weird since if I added it to the 2.8.0 folder, it's not in the 2.8.x branch, but is in master... So for older version updates, I don't bother with the older branches, yes? Just master and the older folders @mwbrooks, when the docs get published to the web at the end of the release, does just edge or all version folders get published? If all folders get published, then correct, no need to commit to old branches, as all users that browse the docs online will see your change in the 2.8.0 folder (which is somewhat confusingly [but cleverly] from master)… unless we ever build a patch release which doesn't seem to happen, with the possible exception of 2.9.x.
Re: Documentation update to previous version
Makes sense. I'll cherry-pick my changes to the relevant branches. On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks mich...@michaelbrooks.cawrote: Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron shaz...@gmail.com wrote: Yeah I'm interested in the flow as well. I think we published everything again in older releases, not sure if we are still doing that going forward On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 17, 2013, at 6:21 PM, Shazron shaz...@gmail.com wrote: Should I bother? I know they will go in edge. There are a couple of issues: https://issues.apache.org/jira/browse/CB-3753 https://issues.apache.org/jira/browse/CB-3752 Basically it's weird since if I added it to the 2.8.0 folder, it's not in the 2.8.x branch, but is in master... So for older version updates, I don't bother with the older branches, yes? Just master and the older folders @mwbrooks, when the docs get published to the web at the end of the release, does just edge or all version folders get published? If all folders get published, then correct, no need to commit to old branches, as all users that browse the docs online will see your change in the 2.8.0 folder (which is somewhat confusingly [but cleverly] from master)… unless we ever build a patch release which doesn't seem to happen, with the possible exception of 2.9.x.
Re: 2.9.0rc1 this coming monday??
Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME. That work is pretty much done. We should have it tested and committed within the next few hours. On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland iclell...@google.com wrote: The only thing that I'm working on this morning that could be a candidate for 2.9 is an extension to FileWriter.write(Blob) that will accept a Cordova File object in place of a native Blob object. (FileWriter.write(Blob) is CB-2406, and new for 2.9) If we consider this a bug to be fixed, then I can take care of it post-rc1. Otherwise, I'll work quickly to get it in this morning. On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj f...@adobe.com wrote: SO: we're doing this today ya? Any objections? Anyone still working on something that they are gunning to get in for 2.9? On 6/14/13 1:12 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Monday RC1 sounds good to me. On Thu, Jun 13, 2013 at 11:19 AM, Shazron shaz...@gmail.com wrote: Looking at iOS 2.9.0: Definitely as you said: https://issues.apache.org/jira/browse/CB-3757 Then all iOS cli and docs issues. If there is time for iOS I am going to tackle: https://issues.apache.org/jira/browse/CB-3303 (to fix) https://issues.apache.org/jira/browse/CB-3451 (to investigate, no fix yet) https://issues.apache.org/jira/browse/CB-3567 (there is a PR to investigate) https://issues.apache.org/jira/browse/CB-3562 (fix in the issue, to evaluate) https://issues.apache.org/jira/browse/CB-3534 (the reporter has filed an excellent bug report, to repro, and maybe fix) Maybe this Untappd issue: https://issues.apache.org/jira/browse/CB-3574 On Thu, Jun 13, 2013 at 11:10 AM, Lorin Beer lorin.beer@gmail.com wrote: be the leaf in the wind, Shaz. Anything pressing on iOS that needs to be resolved? I am aware of a bug in Camera, which I can take a look at. Anything else you want in? On Thu, Jun 13, 2013 at 11:01 AM, Shazron shaz...@gmail.com wrote: I wish I could say there was more velocity in the iOS / OS X repos but there hasn't
BB10 bundling of node.js
I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: 2.9.0rc1 this coming monday??
Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME. That work is pretty much done. We should have it tested and committed within the next few hours. On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland iclell...@google.com wrote: The only thing that I'm working on this morning that could be a candidate for 2.9 is an extension to FileWriter.write(Blob) that will accept a Cordova File object in place of a native Blob object. (FileWriter.write(Blob) is CB-2406, and new for 2.9) If we consider this a bug to be fixed, then I can take care of it post-rc1. Otherwise, I'll work quickly to get it in this morning. On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj f...@adobe.com wrote: SO: we're doing this today ya? Any objections? Anyone still working on something that they are gunning to get in for 2.9? On 6/14/13 1:12 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Monday RC1 sounds good to me. On Thu, Jun 13, 2013 at 11:19 AM, Shazron shaz...@gmail.com wrote: Looking at iOS 2.9.0: Definitely as you said: https://issues.apache.org/jira/browse/CB-3757 Then all iOS cli and docs issues. If there is time for iOS I am going to tackle: https://issues.apache.org/jira/browse/CB-3303 (to fix) https://issues.apache.org/jira/browse/CB-3451 (to investigate, no fix yet) https://issues.apache.org/jira/browse/CB-3567 (there is a PR to investigate) https://issues.apache.org/jira/browse/CB-3562 (fix
Re: 2.9.0rc1 this coming monday??
Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME. That work is pretty much done. We should have it tested and committed within the next few hours. On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland iclell...@google.com wrote: The only thing that I'm working on this morning that could be a candidate for 2.9 is an extension to FileWriter.write(Blob) that will accept a Cordova File object in place of a native Blob object. (FileWriter.write(Blob) is CB-2406, and new for 2.9) If we consider this a bug to be fixed, then I can take care of it post-rc1. Otherwise, I'll work quickly to get it in this morning. On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj f...@adobe.com wrote: SO: we're doing this today ya? Any objections? Anyone still working on something that they are gunning to get in for 2.9? On 6/14/13 1:12 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Monday RC1 sounds good to me. On Thu, Jun 13, 2013 at 11:19 AM, Shazron shaz...@gmail.com wrote: Looking at iOS 2.9.0: Definitely as you said: https://issues.apache.org/jira/browse/CB-3757 Then all iOS cli and docs issues. If there is time for iOS I am going to tackle: https://issues.apache.org/jira/browse/CB-3303 (to fix)
Re: BB10 bundling of node.js
-1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.comwrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: 2.9.0rc1 this coming monday??
I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME. That work is pretty much done. We should have it tested and committed within the next few hours. On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland iclell...@google.com wrote: The only thing that I'm working on this morning that could be a candidate for 2.9 is an extension to FileWriter.write(Blob) that will accept a Cordova File object in place of a native Blob object. (FileWriter.write(Blob) is CB-2406, and new for 2.9) If we consider this a bug to be fixed, then I can take care of it post-rc1. Otherwise, I'll work quickly to get it in this morning. On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj f...@adobe.com wrote: SO: we're doing this today ya? Any objections? Anyone still working on something that they are gunning to get in for 2.9? On 6/14/13 1:12 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Monday RC1 sounds good to me.
Re: BB10 bundling of node.js
So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner gtan...@gmail.com wrote: -1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.com wrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: BB10 bundling of node.js
I would expect they would have a supported node version when they type: npm install cordova which would do any version checks in the package.json [1] for supported node versions [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins br...@bryanhiggins.netwrote: So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner gtan...@gmail.com wrote: -1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.com wrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: BB10 bundling of node.js
For 3.0 will there still be a ZIP file released by Apache? Will the instructions be download the latest version of node then run npm install -g path to cordova-cli? My assumption was the individual project templates will continue to work independently of CLI. Also, keep in mind that CLI invokes BB via shell scripts which in turn call node. So for environments where people need different versions of node installed, invoking CLI with an alternate node version will cause BB to be invoked via the globally installed version. Perhaps that is an edge case, but it's still something that needs to be supported by allowing them to configure node path for BB. On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner gtan...@gmail.com wrote: I would expect they would have a supported node version when they type: npm install cordova which would do any version checks in the package.json [1] for supported node versions [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins br...@bryanhiggins.net wrote: So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner gtan...@gmail.com wrote: -1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.com wrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Fwd: Media API, DataResource, and empty URLs
The automated tests for Media frequently call new Media() with no URL, which sends a null to the create action. In the past, this got turned into the string null in Java, which was handled as a file named null that didn't exist, and nothing crashed. DataResource is fine with the files not existing, but it's not fine with null as a filename since it neither has a URL scheme nor is it an absolute path. Is there a reason why new Media() should work rather than throwing IllegalArgumentExceptions for trying to read files with relative paths? Should I detect and gracefully handle null being given as the media URL in Javascript? In Java? Should I instead change the mobile-spec tests to use file:///dummy or similar? Braden
Re: 2.9.0rc1 this coming monday??
I'll make this change in plugman now. On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME. That work is pretty much done. We should have it tested and committed within the next few hours. On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland iclell...@google.com wrote: The only thing that I'm working on this morning that could be a candidate for 2.9 is an extension to FileWriter.write(Blob) that will accept a Cordova File object in place of a native Blob object. (FileWriter.write(Blob) is CB-2406, and new for 2.9) If we consider this a bug to be fixed, then I can take care of it post-rc1. Otherwise, I'll work quickly to get it in this morning. On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj f...@adobe.com wrote: SO: we're doing this today ya? Any objections? Anyone still working on something that they are gunning to get in for 2.9? On 6/14/13 1:12 PM,
Re: 2.9.0rc1 this coming monday??
Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME. That work is pretty much done. We should have it tested and committed within the next few hours. On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland iclell...@google.com wrote: The only thing that I'm working on this morning that could be a candidate for 2.9 is an extension to FileWriter.write(Blob) that will accept a Cordova File object in place of a native Blob object. (FileWriter.write(Blob) is CB-2406, and new for 2.9) If we consider this a bug to be fixed, then I can take care of it post-rc1. Otherwise, I'll work quickly to get it in this morning. On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj f...@adobe.com wrote: SO: we're doing this today ya? Any objections? Anyone still working on something that they are
Re: BB10 bundling of node.js
Still a -1, cordova (and all it's projects) should use the globally installed version of node. If someone needs multiple versions of node the should probably use nvm [1] to manage it. IMHO this is a user problem and not something we should magically solve via bundled copies of node or hardcoded paths to specific versions of node. I agree we should have a version of node we support, it just needs to be consistent and common across all of our tools and require the user to have that version range in their path. [1] - https://github.com/creationix/nvm On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins br...@bryanhiggins.netwrote: For 3.0 will there still be a ZIP file released by Apache? Will the instructions be download the latest version of node then run npm install -g path to cordova-cli? My assumption was the individual project templates will continue to work independently of CLI. Also, keep in mind that CLI invokes BB via shell scripts which in turn call node. So for environments where people need different versions of node installed, invoking CLI with an alternate node version will cause BB to be invoked via the globally installed version. Perhaps that is an edge case, but it's still something that needs to be supported by allowing them to configure node path for BB. On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner gtan...@gmail.com wrote: I would expect they would have a supported node version when they type: npm install cordova which would do any version checks in the package.json [1] for supported node versions [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins br...@bryanhiggins.net wrote: So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner gtan...@gmail.com wrote: -1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.com wrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: 2.9.0rc1 this coming monday??
JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME. That work is pretty much done. We should have it tested and committed within the next few hours. On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland iclell...@google.com wrote: The only thing that I'm working on this morning that could be a candidate for 2.9 is an extension to FileWriter.write(Blob) that will accept a Cordova File object in place of a native Blob object. (FileWriter.write(Blob) is CB-2406, and new for 2.9) If we consider this a bug to be fixed, then I can
Re: 2.9.0rc1 this coming monday??
Just pushed 0.7.12 of plugman that writes out both .js and .json files. The .js file is wrapped in a cordova.define module whereas the .json file is a simple array of plugins that were added using plugman. Next I will update cordova-js to: 1. Try to load the .json file using an xhr 2. If that throws, it will try to load the .js file by injecting a script tag. I will then test out this action on ios/android/bb10 and get Mapes to test it out on WP. THEN: retag will happen. Will report back shortly. On 6/19/13 1:18 PM, Braden Shepherdson bra...@chromium.org wrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote: For BB10, we're working on moving out the environment settings from project to HOME.
Re: 2.9.0rc1 this coming monday??
Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues anywhere? I'd like to refer other issues (CLI) to this feature you're speaking of. On 6/17/13 10:18 AM, Bryan Higgins br...@bryanhiggins.net wrote:
Re: Documentation update to previous version
I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on master, but not in the 2.8.x branch. Furthermore, the commit that was tagged is not even in the 2.8.x branch. Do I fix this? On Wed, Jun 19, 2013 at 11:51 AM, Shazron shaz...@gmail.com wrote: Makes sense. I'll cherry-pick my changes to the relevant branches. On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron shaz...@gmail.com wrote: Yeah I'm interested in the flow as well. I think we published everything again in older releases, not sure if we are still doing that going forward On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 17, 2013, at 6:21 PM, Shazron shaz...@gmail.com wrote: Should I bother? I know they will go in edge. There are a couple of issues: https://issues.apache.org/jira/browse/CB-3753 https://issues.apache.org/jira/browse/CB-3752 Basically it's weird since if I added it to the 2.8.0 folder, it's not in the 2.8.x branch, but is in master... So for older version updates, I don't bother with the older branches, yes? Just master and the older folders @mwbrooks, when the docs get published to the web at the end of the release, does just edge or all version folders get published? If all folders get published, then correct, no need to commit to old branches, as all users that browse the docs online will see your change in the 2.8.0 folder (which is somewhat confusingly [but cleverly] from master)… unless we ever build a patch release which doesn't seem to happen, with the possible exception of 2.9.x.
Re: Documentation update to previous version
Rhetorical question of course I am fixing this... On Wed, Jun 19, 2013 at 1:36 PM, Shazron shaz...@gmail.com wrote: I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on master, but not in the 2.8.x branch. Furthermore, the commit that was tagged is not even in the 2.8.x branch. Do I fix this? On Wed, Jun 19, 2013 at 11:51 AM, Shazron shaz...@gmail.com wrote: Makes sense. I'll cherry-pick my changes to the relevant branches. On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron shaz...@gmail.com wrote: Yeah I'm interested in the flow as well. I think we published everything again in older releases, not sure if we are still doing that going forward On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 17, 2013, at 6:21 PM, Shazron shaz...@gmail.com wrote: Should I bother? I know they will go in edge. There are a couple of issues: https://issues.apache.org/jira/browse/CB-3753 https://issues.apache.org/jira/browse/CB-3752 Basically it's weird since if I added it to the 2.8.0 folder, it's not in the 2.8.x branch, but is in master... So for older version updates, I don't bother with the older branches, yes? Just master and the older folders @mwbrooks, when the docs get published to the web at the end of the release, does just edge or all version folders get published? If all folders get published, then correct, no need to commit to old branches, as all users that browse the docs online will see your change in the 2.8.0 folder (which is somewhat confusingly [but cleverly] from master)… unless we ever build a patch release which doesn't seem to happen, with the possible exception of 2.9.x.
Re: 2.9.0rc1 this coming monday??
I've pushed a pl branch to cordova-js that combines both loading techniques in the plugin_loader. I am in the process of testing on android/ios/bb10. Benn is working on testing that on the Windows Phone platforms. If it all works out I will merge this back into master on cordova-js, cherry pick into the 2.9.x branch and retag the JS. On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote:
Re: Documentation update to previous version
This commit that was tagged 2.8.0: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=1d2fdf5a3344a554136c505b162d1931e878daad Does not occur in branch 2.8.x: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/heads/2.8.x Nor does the tagged commit occur in master(!) - the commit there has a different sha1: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 So, it was tagged in some unknown branch, not sure where... So I'm cherry picking: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 Into the 2.8.x branch, and tagging that 2.8.0 On Wed, Jun 19, 2013 at 1:40 PM, Shazron shaz...@gmail.com wrote: Rhetorical question of course I am fixing this... On Wed, Jun 19, 2013 at 1:36 PM, Shazron shaz...@gmail.com wrote: I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on master, but not in the 2.8.x branch. Furthermore, the commit that was tagged is not even in the 2.8.x branch. Do I fix this? On Wed, Jun 19, 2013 at 11:51 AM, Shazron shaz...@gmail.com wrote: Makes sense. I'll cherry-pick my changes to the relevant branches. On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron shaz...@gmail.com wrote: Yeah I'm interested in the flow as well. I think we published everything again in older releases, not sure if we are still doing that going forward On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 17, 2013, at 6:21 PM, Shazron shaz...@gmail.com wrote: Should I bother? I know they will go in edge. There are a couple of issues: https://issues.apache.org/jira/browse/CB-3753 https://issues.apache.org/jira/browse/CB-3752 Basically it's weird since if I added it to the 2.8.0 folder, it's not in the 2.8.x branch, but is in master... So for older version updates, I don't bother with the older branches, yes? Just master and the older folders @mwbrooks, when the docs get published to the web at the end of the release, does just edge or all version folders get published? If all folders get published, then correct, no need to commit to old branches, as all users that browse the docs online will see your change in the 2.8.0 folder (which is somewhat confusingly [but cleverly] from master)… unless we ever build a patch release which doesn't seem to happen, with the possible exception of 2.9.x.
Re: 2.9.0rc1 this coming monday??
Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj f...@adobe.com wrote: Thanks Jeff! On 6/17/13 10:28 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, CB-3799 On 13-06-17 1:26 PM, Filip Maj f...@adobe.com wrote: Good stuff Bryan, is this being tracked on issues
Re: 2.9.0rc1 this coming monday??
I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool (Steven - I'm looking at you for the uploading a release part :P). On Mon, Jun 17, 2013 at 1:38
Re: 2.9.0rc1 this coming monday??
Benn and I just tested the pl branch of cordova-js on Windows Phone 7, works well. We are gonna test on WP8 now too. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the
Re: 2.9.0rc1 this coming monday??
Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so I clearly won't get this all done in the next few hours :P. So, I'm fine with starting the release now so that we can focus more on 3.0. It'll give us a chance to practice our release-foo some more, and hopefully make more enhancements to the coho tool
Re: BB10 bundling of node.js
Plugman and cordova-cli both require a minimum 0.9.9 node. See the engines and engineStrict flags in package.json for the two repos. engineStrict when set to true will force npm to make sure the user's version of node adheres to what is listed under the engines prop. On 6/19/13 1:15 PM, Gord Tanner gtan...@gmail.com wrote: Still a -1, cordova (and all it's projects) should use the globally installed version of node. If someone needs multiple versions of node the should probably use nvm [1] to manage it. IMHO this is a user problem and not something we should magically solve via bundled copies of node or hardcoded paths to specific versions of node. I agree we should have a version of node we support, it just needs to be consistent and common across all of our tools and require the user to have that version range in their path. [1] - https://github.com/creationix/nvm On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins br...@bryanhiggins.netwrote: For 3.0 will there still be a ZIP file released by Apache? Will the instructions be download the latest version of node then run npm install -g path to cordova-cli? My assumption was the individual project templates will continue to work independently of CLI. Also, keep in mind that CLI invokes BB via shell scripts which in turn call node. So for environments where people need different versions of node installed, invoking CLI with an alternate node version will cause BB to be invoked via the globally installed version. Perhaps that is an edge case, but it's still something that needs to be supported by allowing them to configure node path for BB. On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner gtan...@gmail.com wrote: I would expect they would have a supported node version when they type: npm install cordova which would do any version checks in the package.json [1] for supported node versions [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f= package.json;hb=HEAD On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins br...@bryanhiggins.net wrote: So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner gtan...@gmail.com wrote: -1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.com wrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_pa rty/node
Re: 2.9.0rc1 this coming monday??
Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked to fix a few more bugs, namely: - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) - iOS loading bugs (CB-3005, CB-3530, CB-3534) - DisallowOverscroll setting inconsistency between Android and iOS (Jesse brought this up - no bug filed for this yet I think) I was also planning on working on adding some Plugin-behaving-nicely checks on the native side. E.g. log a message if a plugin takes spends more than 50ms on the UI (for iOS) or WebCore (for Android) thread. Of course, I haven't done anything for over 2 weeks, and so
Re: 2.9.0rc1 this coming monday??
Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned: CB-3757 , CB-3562. -James Jong On Jun 17, 2013, at 3:21 PM, Andrew Grieve agri...@chromium.org wrote: I would have liked
Re: 2.9.0rc1 this coming monday??
Tag it the ol' fashioned way, then. Not sure why we need magic to do `git tag 2.9.0rc1 git push --tags apache 2.9.x` On 6/19/13 2:50 PM, Jesse purplecabb...@gmail.com wrote: Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them tomorrow morning unless I hear otherwise. On 6/17/13 2:01 PM, James Jong wjamesj...@gmail.com wrote: I'm back this week and will start looking at a couple of the ones Shaz mentioned:
Re: 2.9.0rc1 this coming monday??
Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the version in the .js header is still 2.7.0 - checked the VERSION file is correct. On Wed, Jun 19, 2013 at 2:50 PM, Jesse purplecabb...@gmail.com wrote: Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I have the rc tag issues for mobile-spec and the JS assigned to me. I will tag them
Re: 2.9.0rc1 this coming monday??
Its the magical computeGitVersion in jakefile. Apparently it boils down: $ git describe --tags --long 2.7.0rc1-94-g002f33d Not sure why that returns 2.7.0, nor why we use that instead of VERSION. I suggest moving forward and manually tagging. On 6/19/13 2:52 PM, Shazron shaz...@gmail.com wrote: Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the version in the .js header is still 2.7.0 - checked the VERSION file is correct. On Wed, Jun 19, 2013 at 2:50 PM, Jesse purplecabb...@gmail.com wrote: Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has
Re: 2.9.0rc1 this coming monday??
Just re-tagged, test and fly! I am now getting : // Platform: windowsphone // 2.9.0rc1-0-g002f33d @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:52 PM, Shazron shaz...@gmail.com wrote: Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the version in the .js header is still 2.7.0 - checked the VERSION file is correct. On Wed, Jun 19, 2013 at 2:50 PM, Jesse purplecabb...@gmail.com wrote: Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get
Re: 2.9.0rc1 this coming monday??
Never mind me dum dum. Thanks Jesse On Wed, Jun 19, 2013 at 2:52 PM, Shazron shaz...@gmail.com wrote: Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the version in the .js header is still 2.7.0 - checked the VERSION file is correct. On Wed, Jun 19, 2013 at 2:50 PM, Jesse purplecabb...@gmail.com wrote: Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, Shazron shaz...@gmail.com wrote: I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj f...@adobe.com wrote: I
cordova-ios/iphone/beep.wav
Ian, was this file supposed to be checked in? https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589 https://issues.apache.org/jira/browse/CB-2840 Ran Apache RAT and noticed that one.
Re: cordova-ios/iphone/beep.wav
If you need a wav file for the beep, I have composed a CC licensed file here: https://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=tree;f=common/resources;h=a9558f417570ee1793d34be30b81291750597153;hb=HEAD @purplecabbage risingj.com On Wed, Jun 19, 2013 at 3:30 PM, Shazron shaz...@gmail.com wrote: Ian, was this file supposed to be checked in? https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589 https://issues.apache.org/jira/browse/CB-2840 Ran Apache RAT and noticed that one.
Re: cordova-ios/iphone/beep.wav
Looking at the issue, I don't think it needed a beep.wav, which makes me think this was accidentally checked in On Wed, Jun 19, 2013 at 4:00 PM, Jesse purplecabb...@gmail.com wrote: If you need a wav file for the beep, I have composed a CC licensed file here: https://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=tree;f=common/resources;h=a9558f417570ee1793d34be30b81291750597153;hb=HEAD @purplecabbage risingj.com On Wed, Jun 19, 2013 at 3:30 PM, Shazron shaz...@gmail.com wrote: Ian, was this file supposed to be checked in? https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589 https://issues.apache.org/jira/browse/CB-2840 Ran Apache RAT and noticed that one.
Re: 2.9.0rc1 this coming monday??
Late to the game here, but to re-tag JS: ./cordova-coho/coho tag-release --version 2.9.0rc1 -r js To update JS snapshots in all repos, coho can't handle that yet. I think I'll break updating of JS out into its own command so that we can address this usecase. On Wed, Jun 19, 2013 at 6:05 PM, Shazron shaz...@gmail.com wrote: Never mind me dum dum. Thanks Jesse On Wed, Jun 19, 2013 at 2:52 PM, Shazron shaz...@gmail.com wrote: Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the version in the .js header is still 2.7.0 - checked the VERSION file is correct. On Wed, Jun 19, 2013 at 2:50 PM, Jesse purplecabb...@gmail.com wrote: Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an Access Denied error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1]
Re: Media API, DataResource, and empty URLs
null could be interpreted as a relative URL I think. The current handling of relative URLs by plugins is sadly plugin-specific. On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson bra...@chromium.orgwrote: The automated tests for Media frequently call new Media() with no URL, which sends a null to the create action. In the past, this got turned into the string null in Java, which was handled as a file named null that didn't exist, and nothing crashed. DataResource is fine with the files not existing, but it's not fine with null as a filename since it neither has a URL scheme nor is it an absolute path. Is there a reason why new Media() should work rather than throwing IllegalArgumentExceptions for trying to read files with relative paths? Should I detect and gracefully handle null being given as the media URL in Javascript? In Java? Should I instead change the mobile-spec tests to use file:///dummy or similar? Braden
Re: Media API, DataResource, and empty URLs
On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve agri...@chromium.org wrote: null could be interpreted as a relative URL I think. The current handling of relative URLs by plugins is sadly plugin-specific. Isn't that one of the things that DataResource is supposed to standardize? The string null is certainly a relative URL, and all plugins should interpret that as one. The empty string is a relative url as well. (See the 'image src=' problem). DataResource should probably handle relative URLs; that seems like a deficiency if it can't. We shouldn't be representing the JavaScript null value as null, or as , though. I don't think there's any rational reason to support new Media() as a construct. Media is fairly clearly documented as taking two required parameters, and two optional ones. I don't think Media() makes sense -- it doesn't give you a useful object. The calls to Media() are likely just in mobile-spec, and we should clean those up. On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson bra...@chromium.org wrote: The automated tests for Media frequently call new Media() with no URL, which sends a null to the create action. In the past, this got turned into the string null in Java, which was handled as a file named null that didn't exist, and nothing crashed. DataResource is fine with the files not existing, but it's not fine with null as a filename since it neither has a URL scheme nor is it an absolute path. Is there a reason why new Media() should work rather than throwing IllegalArgumentExceptions for trying to read files with relative paths? Should I detect and gracefully handle null being given as the media URL in Javascript? In Java? Should I instead change the mobile-spec tests to use file:///dummy or similar? Braden
Re: 2.9.0rc1 this coming monday??
Okay, made more sense to just update the existing command to handle this. For next time, we can just re-tag the JS and re-run: ./cordova-coho/coho prepare-release-branch --version 2.9.0rc1 and it will update all the JS snapshots on both master and the release branch. On Wed, Jun 19, 2013 at 10:34 PM, Andrew Grieve agri...@chromium.orgwrote: Late to the game here, but to re-tag JS: ./cordova-coho/coho tag-release --version 2.9.0rc1 -r js To update JS snapshots in all repos, coho can't handle that yet. I think I'll break updating of JS out into its own command so that we can address this usecase. On Wed, Jun 19, 2013 at 6:05 PM, Shazron shaz...@gmail.com wrote: Never mind me dum dum. Thanks Jesse On Wed, Jun 19, 2013 at 2:52 PM, Shazron shaz...@gmail.com wrote: Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the version in the .js header is still 2.7.0 - checked the VERSION file is correct. On Wed, Jun 19, 2013 at 2:50 PM, Jesse purplecabb...@gmail.com wrote: Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron shaz...@gmail.com wrote: Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj f...@adobe.com wrote: Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, Jesse purplecabb...@gmail.com wrote: I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj f...@adobe.com wrote: Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, Jesse purplecabb...@gmail.com wrote: Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson bra...@chromium.orgwrote: JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj f...@adobe.com wrote: Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, Jesse purplecabb...@gmail.com wrote: I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson bra...@chromium.orgwrote: Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson bra...@chromium.org wrote: Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and script tag looks fine. It's hard to make Plugman backward compatible, because it's hard to know which version of cordova.js it's going to be running against. Any ideas here? Braden On Wed, Jun 19, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote: Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the
Re: Media API, DataResource, and empty URLs
Agree that we should make Media() an error, but we don't want to change the semantics of relative URLs for APIs without proper deprecation. On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland iclell...@google.com wrote: On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve agri...@chromium.org wrote: null could be interpreted as a relative URL I think. The current handling of relative URLs by plugins is sadly plugin-specific. Isn't that one of the things that DataResource is supposed to standardize? The string null is certainly a relative URL, and all plugins should interpret that as one. The empty string is a relative url as well. (See the 'image src=' problem). DataResource should probably handle relative URLs; that seems like a deficiency if it can't. We shouldn't be representing the JavaScript null value as null, or as , though. I don't think there's any rational reason to support new Media() as a construct. Media is fairly clearly documented as taking two required parameters, and two optional ones. I don't think Media() makes sense -- it doesn't give you a useful object. The calls to Media() are likely just in mobile-spec, and we should clean those up. On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson bra...@chromium.org wrote: The automated tests for Media frequently call new Media() with no URL, which sends a null to the create action. In the past, this got turned into the string null in Java, which was handled as a file named null that didn't exist, and nothing crashed. DataResource is fine with the files not existing, but it's not fine with null as a filename since it neither has a URL scheme nor is it an absolute path. Is there a reason why new Media() should work rather than throwing IllegalArgumentExceptions for trying to read files with relative paths? Should I detect and gracefully handle null being given as the media URL in Javascript? In Java? Should I instead change the mobile-spec tests to use file:///dummy or similar? Braden
Re: Documentation update to previous version
Thanks Shaz! I was away for JSConf, so another contributor handled the cordova-docs release for 2.8.0. Michael On Wed, Jun 19, 2013 at 1:46 PM, Shazron shaz...@gmail.com wrote: This commit that was tagged 2.8.0: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=1d2fdf5a3344a554136c505b162d1931e878daad Does not occur in branch 2.8.x: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/heads/2.8.x Nor does the tagged commit occur in master(!) - the commit there has a different sha1: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 So, it was tagged in some unknown branch, not sure where... So I'm cherry picking: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 Into the 2.8.x branch, and tagging that 2.8.0 On Wed, Jun 19, 2013 at 1:40 PM, Shazron shaz...@gmail.com wrote: Rhetorical question of course I am fixing this... On Wed, Jun 19, 2013 at 1:36 PM, Shazron shaz...@gmail.com wrote: I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on master, but not in the 2.8.x branch. Furthermore, the commit that was tagged is not even in the 2.8.x branch. Do I fix this? On Wed, Jun 19, 2013 at 11:51 AM, Shazron shaz...@gmail.com wrote: Makes sense. I'll cherry-pick my changes to the relevant branches. On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron shaz...@gmail.com wrote: Yeah I'm interested in the flow as well. I think we published everything again in older releases, not sure if we are still doing that going forward On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard cmarc...@gmail.com wrote: On Jun 17, 2013, at 6:21 PM, Shazron shaz...@gmail.com wrote: Should I bother? I know they will go in edge. There are a couple of issues: https://issues.apache.org/jira/browse/CB-3753 https://issues.apache.org/jira/browse/CB-3752 Basically it's weird since if I added it to the 2.8.0 folder, it's not in the 2.8.x branch, but is in master... So for older version updates, I don't bother with the older branches, yes? Just master and the older folders @mwbrooks, when the docs get published to the web at the end of the release, does just edge or all version folders get published? If all folders get published, then correct, no need to commit to old branches, as all users that browse the docs online will see your change in the 2.8.0 folder (which is somewhat confusingly [but cleverly] from master)… unless we ever build a patch release which doesn't seem to happen, with the possible exception of 2.9.x.
